Improve calculator plugin

[jeremypw]

Fixes #474 Fixes #439

• Accept a wider range of valid bc expressions, including concatenated expressions
• Accept number base and scale expressions
• Reject capitals if no number base expression
• Require at least one numeric expression when not using hexadecimal
• Show the actual result returned by bc, not a limited precision floating point number.

It is still rarely possible to enter strings that are not mathematical expressions that get passed to bc and give a spurious result but to completely prevent this while allowing a wide range of valid expressions is too complex to be worthwhile (at least not in this PR).

[jeremypw]

Simple arithmetic

Hexadecimal to Binary

Binary to decimal

Square root function

Arctangent function

[jeremypw]

Use of variables

[tintou]

I think that we need to introduce tests to ensure that this won't regress

[jeremypw]

@tintou I did think about how to set up tests but left it until the basic concept was approved. I do not think regressions are likely in the sense that correct single expressions that are handled correctly in main are not handled correctly here (they are still just passed to bc) - more likely that new types of expressions or combinations of expressions are not handled correctly.

[jeremypw]

Presumably we would need to introduce testing into master first in order to confirm regressions.

[jeremypw]

Essentially all this PR does is relax the filtering on expressions passed to bc - it does not change the expressions so it is still delegated to bc to either give a correct answer or an error. Theoretically the worst that can happen is that it allows through an expression that bc handles incorrectly.

[jeremypw]

Testing framework now merged in.

[jeremypw]

@tintou I have now incorporated tests for the new functionality. Are you able to review?