Extracts version from ECKey private/public key utility class

The version bytes are unrelated to the majority of all `ECKey` functionality; and should (IMHO) be unrelated to the private/public convenience utility/storage class that it represents.

Private/public keys are not attributable to a network, addresses and wallets (aka collections of addresses) are.
Therefore the abstraction of a network version should be moved there, instead of complicating what should be a simple convenience wrapper.

I have mutated the `ECKey` API to only use the `version` parameter where it is actually necessary (when interacting with WIF or Addresses).

That is:
```
ECKey.toWif
ECKey.getBitcoinAddress
ECKey.toString
```
and
```
ECPubKey.toWif
ECPubKey.toString
```
For `toString` behaviour, the default behaviour is to print the WIF string. 
This remains the same, however `mainnet` is the default output.

For this API to be sane, I would argue that the default `toString` behaviour should be simply `toHex`; to more clearly represent what this storage class is actually representing (private/public keys).
However, this will require changes to HDwallet tests to stop relying on the current `toString` behaviour.  So for the purposes of limited change, I'll wait to see what the response is to this request in general.

I have also renamed `getBitcoinAddress` to `getAddress`, as it could represent any valid network.

I have also removed `toBase58` conversion functions, because they were not converting to base 58, but to the WIF format.
If they are still wanted, I can re-add them, but with functionality identical to that of `toBase64`, except using base 58.

This change also simplifies the `ECKey` tests greatly, as now it is simply testing the functionality of `ECKey` itself, and then individually testing the different networks for valid address generation.

**TL;DR**: The ECKey class doesn't make sense to have a `version`, that is an address/wallet necessary abstraction.  Tacking it on the way it is currently makes dealing with private/public keys more complicated than it should be.