Add state storage feature

[timcanham]

This would be similar to parameters, but it would be state settable and storable by flight software for persistence through reboots, etc. It would not be directly settable by the ground.

Framework:

A new role port type:

FPP:

  @ Port for getting state
  port StateGet(
               $id: FwStateIdType @< State ID
               @ Buffer containing serialized state value.
               @ Unmodified if state not found.
               ref val: StateBuffer
             ) -> StateValid

  @ Port for setting a parameter
  port StateSet(
               $id: FwStateIdType @< State ID
               ref val: StateBuffer@< Buffer containing serialized parameter value
             )

A new FPP statement:

state MyName: FppType

The user would be provided base class functions to read and write state as needed.

A new Svc/StateMgr component`

This component would be a simple file-based component that would:

1. Create a file named id.state upon first StateSet call.
2. Write the state to the file
3. Add CRC
4. Read and validate file when StateGet is called.

[celskeggs]

I really like this idea. However, I'm concerned that calling these "States" will be confusing due to the existing presence of "State Machines," which are totally different. Maybe we can call these "Records," like we have on previous projects?

[timcanham]

Yeah, good point. I was using "state" since I've had conversations with people talking about needing to preserve state (i.e. data) through boots. I could see how that could get confused with state from state machines. Records sounds a little database-ey to me. Is there another term we could use?

[Kronos3]

"Internal Parameter"? We already have "parameter", and "external parameter".

[celskeggs]

That seems even more confusing.

[zimri-leisher]

I recommend we make this into an issue so we will discuss it during CCB. I'll do that now