Add UtAssert bit field check macros

[jphickey]

Is your feature request related to a problem? Please describe.
Bit fields are a common method of storing multiple boolean values into a single data field. UtAssert should provide macros that aid in testing code that uses this type of storage.

Describe the solution you'd like
Add some new UtAssert macros to check bit fields. These macros should include in the log the raw value of the bit field being checked (as a hex number) as well as the specific mask bits being checked for. Two forms should be included, one which passes if the bit(s) are set, and one which passes if the bit(s) are not set.

This should be able to use the same underlying Generic assert helper function, just with a different macro wrapper around it that checks a bit mask.

Describe alternatives you've considered
May use the existing UtAssert_UINT32_EQ/NEQ, in either of these forms:

1. UtAssert_INT32_EQ(BitField, BitField | CHECK_BITS)
2. UtAssert_INT32_EQ(BitField & CHECK_BITS, CHECK_BITS)

Downsides: the resulting log is not quite as concise as it should be:

• Its not clear that this is a bitmask check - as it is logged as a normal value check.
• Only either the raw value (form 1) or the bitmask value (form 2) will be logged. It will not log both pieces of info.
• Values will be logged in decimal/base-10 by default which is not easy to read when examining bit flags - base-16 is preferable.

All of the above should be solvable by simply making a different wrapper macro around the existing UtAssert_GenericUnsignedCompare function.

Additional context
See nasa/cFE#1860 for a use case

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Another downside/limitation to using UtAssert_INT32_EQ in the form that it shows the raw value (1) is that it evaluates the BitField twice - meaning it cannot be directly checked from a return value of a function call. It has to be stored on the stack, which has its own downside (i.e. if the value was from a function call, it should log the actual function being called too, not just the stack variable name that was tested).

[jphickey]

This seems like such a low-hanging fruit, I will submit a quick PR.