Add flag to platform storage to capture UserConfig platform.

[axlan]

No description provided.

[adamshapiro0]

This sentence reads a little oddly. "a flag that does not specify something" takes a second to parse. Maybe "indicating that the platform type is not known" or something like that.

We might want to clarify all of this a little more, maybe a combination of the documentation for these constants and some more detail in the flags field documentation itself. I think flags would be a better place to say how that field is defined for DataType::USER_CONFIG and the other data types. Is flags a bitmask? Or maybe it's a generic integer and a subset its bits correspond to a platform type flag enum, including 0 if platform type is unknown? Or is it a full uint8_t enum with a lot of extra space for the future, but only for platform type? That documentation can @ref these constants.

[axlan]

The use case of this flag is two-fold:

1. It indicates the behavior for backward compatibility.
2. It allows the host FE client user to not need to set flags at all, and it will work by default (the size check is sufficient to catch platform type errors).

The platform should always be known, you implicitly need to know it to form an acceptable UserConfig data blob, so I didn't want to word it that way.

The purpose of this is really only for identifying binaries loaded from disk that aren't associated with a device. Ideally, a customer should never have to set or check this.

[adamshapiro0]

Structurally looks good, but I think we should add more explanation to the flags documentation itself. Right now it's a little unclear how it's defined. "DataType-specific flags" doesn't really tell you what to do with it if you are looking at the doxygen HTML, so you end up having to stumble across the flag constants yourself, and then it's still not 100% clear.