Protobuf splitting to reduce size of what is accessed at runtime

[bsstephan]

From @arntsonl in #1123:

Memory size is getting pretty big, I think its a good time to think about board settings vs user settings protobuf packages. We're at the point where calling protobuf breaks our core1 usb code, so we might want to think deeper on how to break up those two components.

So user settings MUST be under a certain size to ensure we don't break usb host, and board settings can be some big size.

My intuition is that the whole config is a "user config" in that it can be changed by the user, so rather than board vs. user, an alternative way to think about this is firmware initialization config (can be loaded at boot, isn't changed at runtime (instead only changed via webconfig)) vs. runtime config (changes at runtime, e.g. profile number, LS/DP/RS, etc.).

[arntsonl]

Totally agreed on naming:

Boot Config (During Initialization) - huge size limit
Run-Time Config (Changed at Run-Time) - very small, doesn't disconnect usb host on save hopefully

We will have to play with how small/lage protobuf can be before it has an impact on core1 PIOs