feature: Detect board port change after upload (arduino#2253)

* UploadResponse now has 'oneof' clause for better API design

* Added scaffolding to return updated-port after upload

* Upload port change detection (first draft)

* Simplified port detection using a Future-style abstraction

* Perform watcher-flush higher in the call tree

* Do not infer upload port if 'upload.wait_for_upload_port' is false

* Further simplified port detection subroutine structure

* fixed linter issue

* Always return an updatedUploadPort.

Arduino CLI should always return the port after an upload, even in the case
where no port change is expected. The consumer shouldn't be required to
implement "if not updated_upload_port, use original port" logic.

The whole point is that all the logic for determining which port should be
selected after an upload should be implemented in Arduino CLI. The consumer
should be able to simply select the port Arduino CLI tells it to select in
all cases.

* Updated docs

* Perform a deep-copy of upload ports where needed.

Previously only the pointer was copied, thus making changes in
`actualPort` to be reflected also to `port`. This lead to some weird
result in the `updatedUploadPort` result:

{
  "stdout": "Verify 11344 bytes of flash with checksum.\nVerify successful\ndone in 0.010 seconds\nCPU reset.\n",
  "stderr": "",
  "updated_upload_port": {
    "address": "/dev/tty.usbmodem14101",     <------- this address...
    "label": "/dev/cu.usbmodem14101",        <------- ...is different from the label
    "protocol": "serial",
    "protocol_label": "Serial Port (USB)",
    "properties": {
      "pid": "0x804E",
      "serialNumber": "94A3397C5150435437202020FF150838",
      "vid": "0x2341"
    },
    "hardware_id": "94A3397C5150435437202020FF150838"
  }
}

* When updating `actualPort` address, update also the address label.

* Fixed some potential nil pointer exceptions

* Further simplified board watcher

We must acesss the gRPC API only until we cross the `command` package
border. Once we are inside the `command` package we should use the
internal API only.

* Before returning from upload, check if the port is still alive

Now the upload detects cases when the upload port is "unstable", i.e.
the port changes even if it shouldn't (because the wait_for_upload_port
property in boards.txt is set to false).

This change should make the upload process more resilient.

* Apply suggestions from code review

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

* Fixed nil exception

* Improved tracking algorithm for upload-port reconnection

The new algorithm takes into account the case where a single board may
expose multiple ports, in this case the selection will increase priority
to ports that:

  1. have the same HW id as the user specified port for upload
  2. have the same protocol as the user specified port for upload
  3. have the same address as the user specified port for upload

---------

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

Disable DTR clearing on 1200-bps touch (only on Windows) (arduino#2234)

The reason why it was originally introduced:
arduino/Arduino@a6909bd

Why we are removing it now?
* Windows does preserve the state of the RTS/DTR bits on successive
  opening of the serial port.
* The serial library used in the Arduino IDE 1.8.x has a bug when trying
  to set DTR=false, on successive opening of the port the DTR line is
  set back high by the USB serial driver. This works differently from
  the serial library we use in the Arduino CLI, that sets DTR=false for
  good and this change is preserved on the successive opening of the
  port.
* Having the serial port left in a state with DTR=false may cause
  problems to tools uploading later.

It may probably completely removed, but for now, to reduce the testing
surface, it will be disabled only for Windows.

Disable DTR clearing on 1200-bps touch (only on Windows) (arduino#2234)

The reason why it was originally introduced:
arduino/Arduino@a6909bd

Why we are removing it now?
* Windows does preserve the state of the RTS/DTR bits on successive
  opening of the serial port.
* The serial library used in the Arduino IDE 1.8.x has a bug when trying
  to set DTR=false, on successive opening of the port the DTR line is
  set back high by the USB serial driver. This works differently from
  the serial library we use in the Arduino CLI, that sets DTR=false for
  good and this change is preserved on the successive opening of the
  port.
* Having the serial port left in a state with DTR=false may cause
  problems to tools uploading later.

It may probably completely removed, but for now, to reduce the testing
surface, it will be disabled only for Windows.

[skip-changelog] Updated translation files (arduino#2188)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Improved memory usage on core/libraries install (arduino#2187)

This is obtained through the upgrade of the 'extract' library.

Upstream patch: codeclysm/extract#21

[breaking] Fix regression in core caching (arduino#2145)

* Added integration test

* Removing useless constants

* Fixed regression in core caching

* Updated tests

Speed-up lib dependency resolution in some particular cases (arduino#…

…2140)

Updated translation files (arduino#2087)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>