Framework/implement FRAM storage

[w-moretti]

Added implementation of the FRAM storage in the FileTransferService. This service is no longer using volatile memory to store its data frames.

In this implementation, the FRAM design is as follows:

• First 2 bytes (0x00 and 0x01) contains the value of frameWriteCursor.
• Next 2 bytes (0x02 and 0x03) contains the value of frameReadCursor.
• Starting from address 0x04, data is stored in blocks of 236 bytes:
  • First byte contains the size of the frame data (in bytes). A size of more than 0 is used to consider a frame as "valid".
  • Next 235 bytes contains the frame data.

By testing, it seems that the unused FRAM storage is set by default to 255. This can cause an issue if the software reads an FRAM address for the first time and interprets a frame size of 255. Starting from address 0x04, a one-time write has been performed on 200 (current MAX_FRAME_COUNT) data blocks of 236 bytes to set the FRAM content to 0. To accomplish this, a reset function (fileTransferReset) has been added to the FileTransferService that clears all data blocks in FRAM, but also resets the cursors to their default values (write=1, read=0).

[TheDopplerEffects]

Authorship fixed.

[w-moretti]

We could get the cursor values directly from FRAM and get rid of frameReadCursor & frameWriteCursor. FRAM has a VERY high write/read cycles endurance, so no problem there.

[w-moretti]

Changes have been done and PR description has been updated.