Calculator: improve scientific notation support.

Fixes #270.

Scientific notation was not supported in all places.  This should fix
that. I admit the regex is a bit much for me to hold in my head, so I am
not sure if there are now incidentally misparsed queries.

All tests pass, including new ones to cover the broken cases mentioned
in the issue.
Calculator: improve recognition of euro-style numbers.

Fixes #207.

- Add a check to try to determine if they entered more European-looking
  numbers.
- Adjust the output, if so, to make the output imply what happened and
  probably appear more familiar.
- Otherwise, treat any commas as noise to be ignored.

The euro-style check is pretty weak, by design. It only looks to see if
they used . before , thus implying an order for the separators.

Also adds an abstract to reduce `dzil test` scroll-spam
Merge branch 'master' into calc_issues
Apply tidy.
Add code and tests for number disambiguation.

This is still not properly factored, but progressing.
Try to recognize mal-formed numbers.

Also includes some minor comment and layout fixups.

Once we have decided on a style which seems to fit all of the input
numbers, we proceed to confirm that all of the numbers (even the
ambiguous ones) make sense in this format.

So far, this means:
- Doesn't have any characters we don't understand.
- All supposed thousands breaks are followed by exactly three numbers
- If there's a decimal mark, there is only one and it never precedes a
  thousands break.

This is starting to look like something which should be in a library
somewhere.

Even better, it isn't even actually used yet, since the style-checker
happens on a whole expression instead of a term.  Someday.
Deal with number checking in a better way.

It passes all of the tests, but it's still wrong.. for example, parens
will not be "numbery" and so can help numbers evade format detection.

On the upside, it's now much simpler to read and understand. Plus,
rejects queries which have been marked bad in the issues this is intended
to address.
Calculator: deal with parenthesized query strings.

We want to make sure that we catch all of the numbers, even if they are
inside parens, so we add some extra spacing (on request) in `spacing` to
make sure we can find them. I think there may still be a problem with
1E2-style numbers, but that's always been there. :(

As part of this, also switched the "sub" versions back to strings so I
can concatenate for the "numbery" regex.  This is not a big deal
since all the functions are getting built early anyway.

And added some more tests to make sure this works as intended.
Iterate toward more formal query parsing.

This is mostly an attempt to make it easier (for me) to read and
identify everything which needs to be covered in any further
refactoring.

There is one funcational difference:  'c' is no longer an acceptable
constant. I was vaguely bothered that it was the only one with units,
anyway and once it made the parsing of 'cos' turn ugly, I just ripped
it out.

Also added a test for an identifiable regression from a former code
comment.
Reconsider how precision is done.

We want the precision to be just like our input, except when there are
hidden factors in the functions which will cause us to want much more.

Because of how we do this (via `eval`) the func list is almost certainly
wrong. Precisely defining our input is (still) yet to come.

Added some tests to show how we handle very small floats and other
related issues, plus a recommended test from an early issue comment
which I somehow missed.
Calculator: use Math::Trig for trig functions.

Also, to get the value of pi.

In service of this change, also add some additional available functions.
Not so much because I think people were clamoring for secants, but as a
way of expanding expectations for the nascent parser: fix replacement
issues with 'e', better description of what a "function" might look
like, etc.
Calculator: add another FP-related regression test.

In response to a known-bad production result.
Calculator: add support for ln and (mostly) arbitrary base logs

We're only actually doing logs up to base 999.. but I think
anything else is probably people goofing. I can be convinced otherwise,
though.
Calculator: minor cleanups.

- Make ln alias more like others.
- Put named constants in a hash and generate the substitution list
  therefrom.
- Update test and comment text slightly for accuracy.

I had fixed a number of different problems iteratively and didn't
recognize that these changes were viable until now.
Merge pull request #327 from mwmiller/calc_issues

Calculator:  resolve outstanding issues.
FlipText: Add "text" to the trigger word.

"flip", "mirror", "spin", and "rotate" are all very common words, and this instant answer comes up often for queries such as "flip flops". While we don't have a way of setting individual goodies with low priority (all goodies have high priority at the moment), it's important that we control the query space of each one. So in this case, adding a "text" as a requirement will prevent it from triggering on "flip flop", "back flip", etc.
Merge pull request #470 from duckduckgo/jag/flip

FlipText: Add "text" to the trigger word.
Conversions: Only switch to exponent format after 1000000
Conversions: Added comments
Calculator: give result for sin(pi)

Because of floating-point issues, sin(pi) does not come out to exactly
0. It looks like something we try to guard against a couple lines down.

So, if we don't have a defined precision (such that we can let sprintf
worry about the correct answer), we will set these very small values to
0.

This worked fine with things like '1 + sin(pi)' which made the whole thing
more confusing at the start. Thus, this commit also includes a passel of
new tests for things I considered as possible faults, plus one other thing
I wanted to demonstrate working [cos(2pi)].