Investigation/experiment: protobuf exposed via web API for backup and/or webconfig usage

Protocol Buffers has definitely proven itself, and a core observation is it will be more resilient to change than JSON, since we can rename fields in protobuf freely thanks to the field numbers, whereas those renames break JSON between versions. Because the JSON is different, the API methods may or may not break, or they may need additional upkeep, or the webconfig needs upkeep, and so on, to match the new field names.

This has led to us inadvertently breaking the config export (see #656), and the upkeep problem in general means that config backups are incomplete (see #309). There is also an element of discontent about the JSON libraries we use in the firmware to begin with, they are futzy and have buffer limitations, so maybe we can divorce ourselves of that by switching everything to protobuf.

This issue is meant to fiddle with ideas, which I'm going to start by exposing protobuf API endpoints and seeing what we can do with them. This might also have a positive effect on the usability of gp2040ce-binary-tools.

For now, my vague thoughts:

• API endpoint /api/proto/config (GET, PUT)
• reference endpoints /api/proto/foo.proto (GET) where foo is config.proto, enums.proto, etc., probably via fsdata.c
• Confirm I can retrieve and edit configs using the above via gp2040ce-binary-tools?
• See what people think about config backups via the above?
• See if anyone better at React than me can use that to make components better/easier?
• Party!?