Add limitations to quantity parsing logic

[hl662]

Closes #7596

• Improve tests, ensuring default parsing and formatting in core frontend's QuantityFormatter produces equivalent values between each other.
• Update the tokenization logic, adding limits and document them in scenarios where a spacer conflicts with a math operator. In particular:
  • Mathematical operations only apply when it is in between whitespace. So -2FT 6IN + 6IN is equal to -2FT-6IN + 6IN, and -2FT-6IN - 6IN is not equal to -2FT-6IN-6IN.
  • For a value like 2FT 6IN-0.5, if the FormatProps has the spacer set to -, the - sign will be treated as a spacer and not subtraction. However, the 0.5 value will use the default unit conversion provided to the parser, because it's not a part of the composite unit when that composite is made up of only 2 units - FT and IN.

[bbastings]

I only approve of the test changes to make sure the parser/formatter match. Don't know enough about the parsing code and potential separators to say whether this is a good solution. Not supporting * and / makes this a big who cares for me.

[hl662]

I only approve of the test changes to make sure the parser/formatter match. Don't know enough about the parsing code and potential separators to say whether this is a good solution. Not supporting * and / makes this a big who cares for me.

I think the best solution, is to take out math operations like you say and figure out a way to add math support on top of quantity, not bake it in, something similar to what you did with AccuDraw. But that shouldn't be done as part of this PR - we want to slot in an alternative the same time we drop this support. We can open an issue to address exactly this later on

Immediately? I want to address the bug as is and the lack of tests for these cases.

[aruniverse]

fyi @mathieu-fournier

[bbastings]

@hl662 So what's up with this PR, has any decision been made? Also, ideally I'd like a fix backported to 4.11.x so I can remove my hack to make AccuDraw work...

private makeParserHappy(value: string, isAngle: boolean): string {
// TODO: Work around for default length parser not accepting output formatted with dash separator, ex. 20'-6"...
const parserSpec = (isAngle ? undefined : this.getLengthParser());
if (undefined === parserSpec)
return value;
return (FormatType.Fractional === parserSpec.format.type && -1 !== value.indexOf("'-") ? value.replaceAll("'-", "':") : value);
}

[ColinKerr]

I don't think we want to force a white space on either side of the operator.

If we are going to rely on spacing maybe a space before the operator is enough.

Another idea that is more complex is that we know how many segments there could be so we know the max number of separators ... if we see more it must be an operator. If we did this we would still need to do something with spaces to handle cases where a value didn't need all segments. e.g. exactly 12'.

I'd be happy to start simple and say there must be a space before if the spacer character matches the operator.