Support specify hash algorithm in files.add

[alanshaw]

Specify multihash hashing alogrithm

This allows the optional param hash or hashAlg to be passed to files.add in order to specify the hash algorithm that should be used when generating the multihash(es) for the added content.

This PR also is more strict about what query string options js-ipfs-api supports by pulling out the supported params into a new query string object.

It also allows camel case aliases for params that are dash separated. This is because the HTTP API uses dash separated param names, but it is far easier to use camel case param names for internal APIs.

The other reason for allowing these aliases is because this code may be called when talking to a remote IPFS instance via the CLI where the qs params will have already been converted into camelCase.

Change object/get and object/data to accept CIDs

This is necessary because get-dagnode.js uses object/get and object/data immediately after adding files. When specifying --cid-version or using --hash (which has the effect of setting --cidversion=true) get-dagnode.js is passed a CIDv1 not a multihash/CIDv0.

Previously get-dagnode.js was extracting a multihash from a CID and sending that, effectively downgrading a CIDv1 to a CIDv0.

That causes the object to not be found (see ipfs-inactive/js-ipfs-unixfs-engine#185) since you have to retrieve using the same CID version as the data was stored.

This actually brings js-ipfs more in line with go-ipfs. Where both object/get and object/data accept a CID:

# With go ipfs daemon running...
$ ipfs add test.txt --cid-version=1 --raw-leaves=false
added zdj7WdDqrSLbsDNdtsHU5eWAeBukPoKfX9doKuTAphCowKjZR test.txt
$ ipfs object get zdj7WdDqrSLbsDNdtsHU5eWAeBukPoKfX9doKuTAphCowKjZR
{"Links":[],"Data":"\u0008\u0002\u0012\u001f(╯°□°）╯︵ ┻━┻\n\u0018\u001f"}
$ ipfs object data zdj7WdDqrSLbsDNdtsHU5eWAeBukPoKfX9doKuTAphCowKjZR
(╯°□°）╯︵ ┻━┻

requires ipfs-inactive/js-ipfs-unixfs-engine#185