NumberStyler: add proof-of-concept

Considering how all of this works, I'm not sure roles are quite the
right fit. It seems like we might just want a shared "Utility" package
or namespace to let us have access to some common library functions.

DDG::GoodieRole::NumberStyle is a particularly horrible name because
it's not even a role!

Also, the comments suck.

But such is the nature of a proof-of-concept.
NumberStyle: minimal changes for Conversions.

I am not claiming this is entirely the correct way to do this in this
package, just that it works fairly easily to expand the scope of the
Conversions goodie, as well.

Gonna need feedback from @moollaza and @mintsoft.

On the upside, I found a bug in the styler code by writing a test here!
NumberStyle: numbery -> number_re.

A less whimsical name to make it easier for humans to read.
NumberStyle: improve documentation of the `understands` logic.

Updates to comments only (plus a little layout to make it flow better),
based on feedback from @moollaza
NumberStyle: another pass at improving `understands` comments.

Based primarily on feedback from @moollaza:

- Straighten up the English a bit to make it more comprehensible.
- Move comments before the code they describe.
Merge remote-tracking branch mwmiller's 'style_role/style_role' into mintsoft/conversion_calcs

Conflicts:
	lib/DDG/Goodie/Calculator.pm
Conversions: Minor cleanup
NumberStyle: add rudimentary support for exponentials.

Also, minor updates to Conversions to make it work there.

NB: This is clearly not properly factored, yet! This is the first step
to get feedback and improvements from @mintsoft.

- Make number style stuff aware of how to deal with case-insensitive
  expoentials.
- Produce consistent output of such strings.

The display format was chosen to be consistent with the output for
Calculator.  Also, the parsing is not quite correct as you can't have a
mantissa in the exponent, but this won't catch that.

Should we also do "for_display" on the factors for consistency?

Any and all feedback or improvements are appreciated.

This also breaks the Calculator tests, but I will worry about fixing
those once everything stabilizes.
Conversions: style the factors as well as the results

This may (or may not) give a nicer look and more clear understanding of
how the input was interpreted.

Looking for feedback from @mintsoft on whether or not this is actually
better.  (Take a look at the test changes in particular to see the
effects.)
NumberStyle: tighten up check for exponentials.

Also, some adjustments to Calculator to allow its tests to pass.
Still clearly not properly factored, but at least everything "works"
for the moment.
NumberStyler: improve number-matching regex.

The major change is matching the exponentials more carefully.  They only
count if they have <number>E<integer> otherwise they won't work.

Also include a suggested change from @mintsoft to better handle the
spacing of numbers and units in Conversions, by separating them using
our defined regexes.

All-in-all, much more resilient!
NumberStyle: add with_html method.

This also required some additional changes to how number_regex is
computed.  That was sort of overdue, anyway.

HTML styling is simply display styling plus super-scripted exponents, at
thispoint.
Conversions: do not encode entities on numbers.

This otherwise encodes the <sup> tags, rendering them impotent. This
might not be exactly the right solution, either.
NumberStyle: allow for negative numbers.

By extension, this also permits negative exponents.

Also breaks a calculator test with a crazy expression where we can't
differentiate between subtrction and negative numbers.  Leaving it
broken for now, since the tokenizing is known broken, anyway.
Conversions: adding missing test for `$unit from $x $unit` style query
Numberstyler: Datadriving number_style_regex
Conversions: removing unnecessary + from guard regex
Conversions: Cleaning up a little
NumberStyle: only allow negative numbers at start.

This allows for us to continue to style negative numbers, but to assume
that "embedded" `-` characters are atually operations.

It's quite an ugly hack.. and this whole quasi-state machine needs
revisited, but this gets everything working for now.
NumberStyle: more hackiness for negative numbers.

Basically, we're only going to recognize negative numbers when they
appear at the beginning of an expression.  Otherwise we assume we don't
needs to deal with them.

I'm sure this causes other problems, but resovles the testing issues for
now.