feature: add bitfield operations for `enumeratedValues` generated types

This is a feature request and/or tracking issue for adding bitfield operations to enumeratedValues generated enum types.

I would like to open discussion about whether bitfield operations are desired for enumeratedValues generated types.

From those more experienced with embedded/SVD development, are enumeratedValues types meant to be explicitly "only these exact values are expected to be read/written"?

Or is it more like C enums where you can perform bitwise operations on the values?

For example, lets say a field has three variants, which may show up alone, or any combination of the three.

Currently there is no way to express the above semantics.

The example in code:

/// Represents a field with bit range [3:0]
pub enum SomeEnumValues {
    FieldValue0 = 0b0001,
    FieldValue1 = 0b0010,
    FieldValue2 = 0b0100,
}

So, the field should be able to express any combination of the FieldValue[0,2] variants, but never set the highest bit. Even though the bit range spans 4 bits.

I have run across a number of field definitions that resemble the above situtation.

Currently, it is obviously possible to just define the fields without an enumeratedValues definition, and document the semantics in the field description.

However, it would be nice to be able to define the semantics in the type system using something like types provided by the bitflags crate.

If this is something maintainers, and the wider community, would like implemented, I am happy to contribute code.

Start by resolving whether enumeratedValues represent exact values or composable bitfields, using the SomeEnumValues example and the linked bitflags crate as discussion context. The issue names no source files or tests; done would require an agreed representation and clearly defined generated behavior for valid combinations and reserved bits.