Update AnnotationMbdControlFrame to more closely follow standards

[camerondix]

The current AnnotationMbdControlFrame shape is both more restrictive and more permissive than the gd&t standards.

Current shape:

pub struct AnnotationMbdControlFrame {
    ///Geometric symbol, the type of geometric control specified
    pub symbol: MbdSymbol,
    /// Diameter symbol (if required) whether the geometric control requires a cylindrical or diameter tolerance
    pub diameter_symbol: Option<MbdSymbol>,
    /// Tolerance value - the total tolerance of the geometric control.  The unit is based on the drawing standard.
    pub tolerance: f64,
    /// Feature of size or tolerance modifiers
    pub modifier: Option<MbdSymbol>,
    /// Primary datum
    pub primary_datum: Option<char>,
    /// Secondary datum
    pub secondary_datum: Option<char>,
    /// Tertiary datum
    pub tertiary_datum: Option<char>,
}

• Describing the datums with a single char is not always possible. The standard allows for 2 character datum names once the alphabet is exhausted, ie AA or AB.
• symbol, diameter_symbol, and modifier are typed using the MbdSymbol enum but the standards are more restrictive in that:
  • the geometric symbol is represented by a 12-14 length subset of the symbols in the MbdSymbol
  • the diameter symbol can optionally be represented by 1 symbol in MbdSymbol
  • the modifier symbol is more loosely defined in the standards, but the set of geometric symbols for example, would not be appropriate to use as modifier symbols

Why it matters:

• This can cause issues down stream, like when exporting to a standardized format that includes MBD, like STEP AP242. Should we let the user create a bad feature control frame then fail to export it because it doesn't meet the requirements? Or do we allow for export and let other importers fail to read it?

Spontaneous solution:

• Use a String instead of a char for datum names to allow for additional datum names.
• Use a bool for the diameter symbol to indicate presence.
• Split the MbdSymbol enum into two sets, geometric and modifiers, to restrict symbol use to the domain they make sense in.

[paultag]

Some general hot-takes:

• I think it's worth us thinking through a GD&T model that doesn't take into account specifics of export formats
• I think we should throw an error as soon as possible
• It should be incredibly hard to construct something illegal that is accepted
• Specific exports (e.g., STEP 242) should map to our grand unified GD&T model rather than us tying ourselves to something specific (e.g., if we wanted to do something fun with glTF that wasn't 242, etc).

[paultag]

may be worth some thinking by:

• KCL (prob @jtran since I know he knows the GD&T stuff super well)
• someone from the rust-end-of-engine (maybe @adamchalmers?)
• I'm hopeful we can do this without touching the engine but in case we do, also would be worth a glance from @mlfarrell

[mlfarrell]

my short term priorities are overloaded, but can be adjusted compared to others depending on customer need. check both my "fifo" (long, harder stuff) and my "box" (easier one-off items). This likely is FIFO territory.

Best way to get this scoped sooner than later is by coming from the opposite end (max's product roadmap)