Create consistent SB transmit/receive API's, refactored to utilize the zero copy pattern

[skliper]

Is your feature request related to a problem? Please describe.
Duplicated logic in CFE_SB_SendMsg and CFE_SB_ZeroCopySend (and related APIs), refactor could simplify CFE_SB_SendMsgFull. Sending/receiving software bus buffers vs the less restrictive alignment message type is not clear, names don't mirror.

Describe the solution you'd like
Implement the following:

• CFE_SB_TransmitMsg - sends the less restrictive alignment message type by coping it into a SB buffer, then transmitting buffer
• CFE_SB_TransmitBuffer - sends a message that is already in a software bus buffer (like CFE_SB_ZeroCopySend)
• CFE_SB_ReceiveBuffer - the old CFE_SB_RcvMsg (it's not a message, it's a buffer)
• CFE_SB_AllocateBuffer - the old CFE_SB_ZeroCopyGetPtr
• CFE_SB_ReleaseBuffer - the old CFE_SB_ZeroCopyReleasePtr

Possibly add flag for incrementing sequence count (instead of more API's like CFE_SB_PassMsg).

Describe alternatives you've considered
None

Additional context
Came from #1009 discussions

Requester Info
Jacob Hageman - NASA/GSFC

[jphickey]

I like the idea of getting rid of the "Pass" variants - or at least justify why we would need to send messages that don't increment the sequence count. This seems like an odd thing to do - because the whole point of a sequence count is for a receiver to know if they missed one. If we duplicate sequence numbers then it would defeat the purpose.

[skliper]

SBN needs it...

[skliper]

Fixed in #1015, just didn't rename CFE_SB_ZeroCopyGetPtr and CFE_SB_ZeroCopyReleasePtr. Open a new issue if renaming these is required.