Implement message dispatch table within SB for unified validation and invocation of handler

[jphickey]

Is your feature request related to a problem? Please describe.
Most (but not all!) applications use a big switch statement to interpret the MID and command code, and invoke a handler.

Problem is:

• Still done very inconsistently. Styles of this switch vary significantly in terms of where the checks are done, and the type of validation that is done (some apps still don't do length checks before casting)
• Fundamentally still requires interpretation of MsgId as integer value, because a switch in C only works on integer values. Ideally apps should treat MsgId as opaque, not do any local interpretation of the value.
• Some apps don't use the switch approach at all, implementing a dispatch table instead. Notable examples are TBL services, and the CF app. While these both use the general concept of a table lookup to a function pointer, they are implemented pretty differently.

Describe the solution you'd like
The dispatch table is a cleaner design, since it allows the application code to be more agnostic to how MIDs work. Notably, the part that interprets/matches the MIDs can be put into SB, thereby no longer requiring the app itself to interpret/match the MIDs.

But rather than letting every app individually migrate to this pattern and have each one done differently, the framework should preemptively add a generic dispatch routine within SB.

The generic function should:

• Validate the initial message MID coming in (does it match any known MID in the table)
• Interpret and validate the command code, if the msg has one (does it match any known CC in the table)
• Confirm that the length of the message is correct
• Cast the message to the correct "real" type and invoke the handler function that was provided from the app.

Describe alternatives you've considered
See TBL services and CF app, its the same idea.

Additional context
Framework needs to add this alternative method of dispatching first, but apps wouldn't be required to use it (backward compatible).

The framework apps in Draco could all be converted to a dispatch table. But GSFC and other external CFS apps would continue using their existing methods in order to remain "Caelum-compatible" but could be updated over time to the unified dispatched as warranted, if/when changed for other reasons....

This is also somewhat related to/part of #994 ... it would cover one of the items listed in there (generic length check)

Requester Info
Joseph Hickey, Vantage Systems, Inc.