Update UnitUtil tests and code

[dpvc]

This PR updates the tests for UnitUtil.ts and adjusts the code:

• In original line 98, since we know (from line 94) that we have mu units, that means value will not be an empty string, and so the || '1' is not needed.
• In original line 146, we know factor is defined, since the UNIT_CASES.get() function in the previous line will return the value for 'pt' (line 65) if the unit itself is not found. So unless someone deletes the 'pt' value, the factor should always be defined, and if it turns out to be 0, then factor * m will be 0, so there is no need for the test.

[zorkow]

• In original line 98, since we know (from line 94) that we have mu units, that means value will not be an empty string, and so the || '1' is not needed.

I tried to work out why this holds. The real reason is that muReplace is only ever called from matchDimen where the current regexp guarantees that there is a numerical value before the unit. However, one could replace the num field in UNIT_CASES with a regexp that would allow for an empty value, which would lead to an error in the parseFloat expression. The following will do the trick:

UnitUtil.UNIT_CASES.num = '([-+]?([.,]\\d*|\\d*([.,]\\d*)?))'
UnitUtil.UNIT_CASES.set('mu', 1/18);

• In original line 146, we know factor is defined, since the UNIT_CASES.get() function in the previous line will return the value for 'pt' (line 65) if the unit itself is not found. So unless someone deletes the 'pt' value, the factor should always be defined, and if it turns out to be 0, then factor * m will be 0, so there is no need for the test.

[dpvc]

one could replace the num field in UNIT_CASES with a regexp that would allow for an empty value

Is that a reasonable thing to do? (That is, is this a use-case that we need to support?) Or would this regex be considered a mistake, and we would want something to go wrong so that the user knows it should be fixed? Because this is being used to determine when a dimension is the first (or only) thing in a string, and dimensions in TeX require numbers, it seems to me that such a regexp would lead to all kinds of trouble.

I'll change it and make a test for it if you want, but I just want to make sure that it is actually a reasonable regex to use for num.

[zorkow]

as per f2f we don't worry about that case now.