Fix the use of '%' in ParseTests

[McNeight]

No description provided.

[angularsen]

Hi, thanks for the PR. Could you please refresh my memory on what this test actually tests and why you wanted to test for %% instead of %? I'm honestly puzzled by the purpose of this unit test, as it seems we want to allow parsing say 10 m!s as 10 meters. I think it was part of supporting parsing things like 1' 2" as feet/inches, but I don't think it makes much sense for Length and most other quantities.

This issue explains how the parsing is currently way too lenient and needs to be tightened a bit.
#343

This comment explains how we want to fix this, but it is a breaking change and can only be added in a major version bump.
#180 (comment)

[angularsen]

@McNeight Just a follow up, I'm waiting for your feedback on how to proceed here.

[angularsen]

Need some feedback to continue.

[McNeight]

I apologize for the delay in responding. As part of a regression test to make sure my changes didn't break anything, I ran the existing test cases and this popped up as a failed test for me.

I originally believed that the failure was due to "%" being treated as a special token within the string that needed to be escaped as "%%". I'm now unable to reproduce the original failure with a single "%", so I'm not sure what happened.

I'll take a look at the other issues you listed and dig into it a bit more, but this might be a non-issue.

[angularsen]

Just a heads up that #487 will re-implement the parse methods to be much more strict and only allow the format Length.Parse("1 m") and possibly "1m".
I propose we close this issue as it will be no longer relevant after that change is made. Please reopen the issue if there is more to discuss here.