Fix inconsistent unit parsing

[a-gagnon]

Problem:

The current Parser implementation is inconsistent when it comes to handling invalid tokens. When the parser spec contains a unit definition such as units: [{ label: "ft", name: "Units.FT" }])`, we would expect that an invalid token would simply convert the value based off that unit as a fallback, but it doesn't.

This is what parsing returns (output is always meters):
"4.0 ft" ==> 1.2192
"1.234 m" ==> 1.234 Even if we're in feet, there is a known unit that uses the m token (meters), so it interprets it correctly.
"4.0" == > 1.2192 Unitless will use the parser's spec unit definition which is Units.FT to convert the value.
"4.0 abcdef" ==> 4.0 This should have outputted 1.2192. The abcdef token does not relate to any known unit. This should be treated as unitless which would have applied the conversion factor properly.

Fix:

Make sure we consider the unit definition when we fail to find any unit matching the token.

Parsing returns properly for all existing cases, including this one:
"4.0 abcdef" ==> 1.2192

Misc:

When we're parsing two tokens and the unit comes first (eg. currency conversion), just swap the entries in the 'token' array rather than duplicate the logic/code.

[raplemie]

@ColinKerr @calebmshafer Any chance this could get reviewed at some point ? Thanks.