Use std::make_unique

[mikee47]

This PR improves use of std::unique_ptr by using std::make_unique where appropriate instead of reset(), and also updating some class constructors to use direct assignment.

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r23-use-make_unique-to-make-unique_ptrs

[what-the-diff]

PR Summary

• Applied std::make_unique in various parts of the code

  The code now uses std::make_unique in place of the new keyword across a multitude of files and functions. This change enhances memory safety and makes the code easier to maintain. This modification is applied to the constructors of many files like TaskStat.cpp, TcpClientTransport.h, RbootHttpUpdater.h and more.

• Removed Redundant reset Calls

  This PR includes the removal of redundant reset calls in several files including uart_server.cpp, wifi.cpp, and AccessPointImpl.cpp. This helps streamline the code and remove potential areas of inefficiency.

[slaff]

@mikee47 can you rebase this PR?

[mikee47]

Looking at the Codacy issues:

Member variable 'Decompressor::dict' is not initialized in the constructor.

Don't care. block of memory gets overwritten. No advantage really in spending time zeroing it out.

Condition '!decompressor' is always false

That implies std::make_unique can throw exceptions. I've tested it running on Esp8266 and can confirm there is a difference. For example:

	auto mem = new uint8_t[128000];

Gives mem = nullptr, whereas this:

	auto mem = std::make_unique<uint8_t[]>(128000);

Raises a fatal STORE_PROHIBITED exception.

I'm changing this PR to WIP as we need to consider this further.

[mikee47]

OK, so the reason why new uint8_t[] and std::make_unique differ is purely because the second one default-initialises the allocated data. If the allocation fails, then attempting to write to location 0 (null) raises the exception. I was aware of this distinction whilst making these changes so removing the WIP tag.

For the Esp8266 at least, new by default does not throw exceptions. Presumably as long as we've disabled exception handling in the C library this is what will happen. Codacy assumes standard behaviour hence the warning.