[Thunderscope] Save and load parameters proto

[itsarune]

By default, changing default protobuf value results in most files to be recompiled which could take a few minutes. We should avoid long recompilation times during Robocup, specially during matches.

[Mr-Anyone]

Maybe look into this?

https://github.com/bazelbuild/bazel/issues/7095

[nimazareian]

Currently, the way the ProtoConfigurationWidget widget works (aka the parameter tree widget in Thunderscope) is that everytime a value is modified by the user, this callback is called which sends the updated ThunderbotsConfig proto to our fullsystem backend (C++) over unix sockets (similar to how we communicate all other protos, but this time it's from Python to C++). The updated config is then dependency injected into AI which passes it down to all parts of AI that require the parameters.

A way of avoiding having to manually update parameters.proto with the new constant values is to serialize the latest ThunderbotsConfig proto that the parameters tree in Thunderscope is visualizing, and store it in a file. This would be similar to how we serialize and store arbitrary protos as part of our replay in ProtoLogger. We probably do not want to save the protobuf everytime the user makes a change to it, since we often play around with the constants without wanting to make it private. Instead, we should consider having a save button in the ProtoConfigurationWidget widget which can be manually triggered to save the parameters. The serialized protobuf should probably be stored in a hard coded path such as /opt/tbotspython that we all have, similar to how we can currently save custom Thunderscope layouts here.

In addition to saving these parameter protos to a file, we will also need to load them at the start of Thunderscope from the saved file (if it exists). This behaviour would likely be also similar to how layouts are loaded at launch of Thunderscope. Once the saved proto is loaded, we would then need to forward it to AI (would need to becareful with possible race conditions here of us sending the proto before fullsystem is finished launching and listening to the unix socket), and we would also need to initialize or update the ProtoConfigurationWidget with it.

In case we don't want to keep using our latest changes, we should also have a reset button that resets the parameters to the default ones (i.e. just create a default ThunderbotsConfig proto). It's probably a good idea to have this button launch a pop up that double checks that the user actually wants to reset the protos and they haven't accidentally pressed it. Once we have reset the parameters, we should be using that in future launches of Thunderscope.

Bonus

• As part of saving the protobuf, it would be great if the user could provide a custom name for the file such that we could store multiple different
• It would also be great if the user could load custom serialized parameters proto files. This would allow us to share our serialized files, while also having the ability to store multiple serialized files locally, and having the option to choose between them depending on the scenario (e.g. have one set of constants for games, but another set of constants that we're testing with during practice). This behaviour would be similar to how we can load arbitrary Thunderscope layout files using Ctrl+O shortcut, and have the loaded layout be used in all future instances of Thunderscope, until we've saved a new layout, reset it, or opened a different layout. For this feature we could have an open button next to the save button previously mentioned that opens a QFileDialog.

As you can probably tell, there's a lot of resemblance between the requested feature and how we can save and load layouts. So I would recommend that you familiar your self with these functions in Thunderscope: save_layout, load_layout, and reset_layout. Though note that the approach used for the layouts is not necessarily the only or the best approach, so feel free to try other methods if you think theyre better.

cc: @Mr-Anyone