Ecmath

Added an EcMath class, which accepts a numeric value or a PointInterface.
Added an interface, covering add(), mul(), getDouble(), mod(), and cmp(), and result(). 

There are tests for the EcMath class, mainly just asserting some operations like (k+k)*G = (k*G)+(k*G). 
Test.php has some examples of usage. (Private/Public classes are not the classes used in this library)

The library tolerates you trying to add an integer to a point, by carrying out the point multiplication when required. 
It will throw an exception if you try to do something impossible, like multiplying two points together.

I haven't added an equals() function, like the Point and Math class both have, though I will probably add this shortly.  Also want to refactor the Math, EcMath, and Crypto components into namespaces, after we discuss it.
For the debug decorator, it implements the same interface (MathAdapter) as the BC/GMP implementations. So whereever you use a MathAdapter, you can use the DebugDecorator just the same, it just works :)

To solve the confusion on usage of the DebugDecorator, we should add to EccFactory::getMathAdapter an optional $debug argument defaulting to false. When true, the created adapter is wrapped in a DebugDecorator, and voilà, problem solved:

```
public static function getAdapter($debug = false)
    {
        $adapter = null;

        if (extension_loaded('gmp')) {
            $adapter = new Gmp();
        }
        elseif (extension_loaded('bcmath')) {
            $adapter = new BcMath();
        }

        if ($adapter == null) {
             throw new \RuntimeException('Please install either GMP or BCMath extensions.');
        }

        if ($debug == true) {
             $adapter = new DebugDecorator($adapter);
        }

        return $adapter;
    }
```

Regarding the EcMath factory method, it's a bit trickier. I'm fully against static methods in interfaces. This is another of PHP's OO non-sense. Static methods "normally" require to be invoked against a type, not an instance. In that case, it's utterly pointless against an interface type (since the declared static method in the interface can have no body, you'd have to implement the static method on all three implementations). But PHP allows to invoke a static method on an instance, working around that issue. But then, you can just make an instance method and conform to proper OO design :p .

I think in the end the cleaner way of implementing it is to add the factory method to the MathAdapter interface. As you mentionned, it would require to implement it in all three implementations (DebugDecorator, Bc, GMP). That issue can be solved by introducing an abstract MathAdapter implementation that only implements the factory method, and have all existing implementations derive from that abstract class.

But the more I think of it, the more I'm convinced neither MathAdapter (one level too low, though it's the most convenient option) nor EccFactory (one level too high) are proper places to have that method. I think we should let that idea sink in for a bit before actually going further with it, and merge this P/R in the meantime (the refactoring won't be much work, nor be risky), and just clearly comment EcMath saying not to use it publicly.