Add singular and plural units to from_str impl. #212

[bheisler]

This adds the singular and plural unit strings to the match in from_str, which means that strings containing them can be parsed.

I found that there are a number of quantities in uom which have at least one unit where the singular and plural is the same. There is also pressure, where pounds-per-square-inch is defined in two different ways. Because of this, the match sometimes includes multiple arms with the same string, resulting in a compiler warning. I've ignored this warning just on the generated match.

I've also updated the tests to check that the expected strings can be parsed.

[Aehmlo]

Seeing that it's an explicit test case, I gather that e.g. "1 meters" parses. I just want to make sure that this is the desired end result. In my applications, I would expect an attempt to parse such a string to be suggestive of a bug elsewhere. I do suspect that checking this edge case may be nontrivial, though, and we probably don't want to get too far into input validation. I guess it comes down to the concept of a balance between human-friendly, permissive parsing vs. stricter parsing discussed in #212.

[bheisler]

I think that disallowing "1 meters" would require a strange edge-case in the code for little to no benefit, so I would recommend allowing it. It's up to you though.

Validation rules like that perhaps make more sense to define at the application level.

[iliekturtles]

Thanks for the PR! I'll review in more depth tomorrow. I feel like there should be more test cases but I'm not sure what they could be yet.

[iliekturtles]

The current code can be simplified:

                        match unit.trim() {
                            $($abbreviation | $singular | $plural => Ok(Self::new::<super::super::$unit>(value)),)+
                            _ => Err(UnknownUnit),
                        }

We could also consider only matching singular when value.is_one() and plural when not. This would require separate matches as written currently in order to fit the match guards. If we do end up going this route then only one macro iteration $(...)+ is needed around all three lines instead of one on each line.

[adamreichold]

We could also consider only matching singular when value.is_one() and plural when not.

As @bheisler said above, being strict in this sense seems to provide little benefit especially when parsing user input. I would suggest erring on the side of lenience here following the parsing adage "be lenient in what you accept, be strict in what you generate".

[bheisler]

I've updated it to simplify the code, as suggested.

[iliekturtles]

Thanks again for the PR!