Inventory.yaml edge case can break structure and prevent Arduino IDE 2.0 from starting

[ubidefeo]

Describe the problem

While investigating an IDE 2 startup failure we noticed that starting the IDE via command line would output a mention to inventory.yaml and the offending error kept on repeating until the process was halted.
Deleting inventory.yaml allowed the IDE to start successfully.

I have spent some time trying to break it and found out that adding a character that breaks a string can prevent the CLI from successfully loading it and returning this error:

Error: reading inventory file: While parsing config: yaml: line 38: did not find expected key

The error came after some heavy fiddling with a platform relying on the presence of MingW32 (Windows) being installed (with failure) on a Mac OS machine, but trying to reinstall it, compile and other operations did not end up breaking the inventory file, so this might as well be an edge case not easy to come by.

To reproduce

Launch IDE, quit and open ~/Library/Arduino15 (different path on Windows/Linux)
break one of the strings adding a random ' character into it as in

    v3/boards/byvid/pid/0x303a/0x1001:
      data: '[{"name":"WCH;32?'","fqbn":"esp32:esp32:esp32s3camlcd"}]'
      ts: "2023-06-21T18:08:39.077936+02:00"

(notice the ?' sequence after WCH;32)

run some CLI operation such as arduino-cli core list

Expected behavior

In case a broken inventory file is encountered, the CLI should clear its content and gracefully handle it.

Arduino CLI version

0.33.0

Operating system

macOS

Operating system version

Ventura

Additional context

Arduino forum: https://forum.arduino.cc/t/macos-m1-arduino-ide-2-0-3-is-not-working-anymore/1078952/13

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the nightly build
• My report contains all necessary details

[cmaglie]

This should be fixed by #2232.

Now I'm wondering how is it possible that inventory.yaml gets corrupted since we use a yaml encoder... It may be a bug in the encoder?

Do you have any clue on how to reproduce it without manually changing the yaml?