* Made PackageManager.TempDir private

* Merged InstallToolRelease function into the proper packagemanager method

* Moved uninstallToolRelease into the proper packagamanger method

* Moved uninstallPlatformRelease into the proper packagamanger method

* Moved downloadToolRelease into the proper packagamanger method

* Merged downloadTool with the proper packagamanger method

* Merged downloadPlatform with the proper packagamanger method

* Moved installPlatform into a packagamanger method

* Moved upgradePlatform into a packagamanger method

* Made PackageManager.Log field private

* Removed the massive code duplication in the 'upgrade' command

* Removed the massive code duplication in the 'outdated' command

* Updated docs

* Update arduino/cores/packagemanager/install_uninstall.go

Co-authored-by: per1234 <accounts@perglass.com>

* Update arduino/cores/packagemanager/install_uninstall.go

Co-authored-by: per1234 <accounts@perglass.com>

Co-authored-by: per1234 <accounts@perglass.com>

`github.com/arduino/arduino-cli/i18n.Tr` provides a `fmt.Printf`-style interface, where the first argument may serve as
a template filled by subsequent arguments according to its format verbs.

This call contains a subsequent argument, but no verb in the format string to use it. This generates some cryptic
content in the error message.

For example:

Error during install: Error downloading tool arduino:bossac@1.7.0-arduino3: no versions available for the current OS%!(EXTRA *cores.ToolRelease=arduino:bossac@1.7.0-arduino3)

The tool name is already provided in the correctly configured `Message` field of the error, so there is no need to
include it in the `Cause` field as well, so the spurious argument can be removed entirely rather than the alternative
fix of adjusting the format string argument. I suspect the spurious argument was simply the result of a copy/paste error.

Now the DiscoveryManager is able to start the discoveries and add/remove
them in a thread-safe way. Also the watchers may connect and disconnect
seamlessly at any time, the incoming events from the discovery are
broadcasted correctly to each active watcher.

This refactoring dramatically simplifies the DiscoveryManager design.

it will be useful in the next commits.

there is already a cache in the DiscoveryManager there is no need to
duplicate it.

otherwise the discovery may send some events before the eventChan is
setup (and those events will be lost)