Added gulp task to concat /examples/*.js into ./examples.md
Updated readme.md
 -removed old examples
 -added link to new examples.md

 Do not forget to run "gulp" everytime you make changes in examples folder.
add check function for BIP39

fixes #393
serialize payment request for signature
add test for setObj
add sign/verify with pki_type SIN

...which is much easier to implement than X.509 certificates.
change bundle name
add new bundles and symbolic link
minify browser version
up version to 0.1.25
Merge remote-tracking branch 'yangit/examples'

Conflicts:
	package.json
modify README and commit examples.md

...to reflect usage of gulp, which automatically builds the examples.md file
from the examples in the examples/* directory.
Merge remote-tracking branch 'devrandom/bip39a'
Merge branch 'feature/bip70-signing'
Merge remote-tracking branch 'maraoz/feature/bundle-name'

Conflicts:
	browser/bitcore-0.1.24.js
add "real" 0.1.24 and 0.1.25, and...

In this commit I have added the 'official' versions 0.1.24 and 0.1.25 to the
repo, and also created a new bitcore-dev.js that is not included in the repo.
bitcoin-dev.js is what we will use for development. When we define a new
version, we create a new bitcore-x.x.x.js file, and point bitcore-latest.js to
that. Note that the bitcore-x.x.x.js files should always be the "main" bundle,
which does not include BIP39 or BIP70, or other large packages.
up version to 0.1.26
test vector that passes in node, but fails in browser/sjcl

There is some kind of problem either in bitcore or sjcl involving the
decodeURIComponent function. I discovered this issue while working on the
network protocol for Copay.  Decrypting binary data in sjcl produces problems
due to the way sjcl is interpreting data as strings. I will have to investigate
further tomorrow. For now I am producing this test vector to demonstrate the
issue.
fix string/buffer sjcl issue

...by using sjcl.mode.cbc.encrypt/decrypt rather than sjcl.encrypt/decrypt. The
difference is that the sjcl.encrypt/decrypt functions are really convenience
methods designed to encrypt and decrypt strings, but don't play nice with
binary data, as revealed in the tests in this commit and the previous commit.
Basically, if you use them to encrypt and decrypt binary data as a string, it
will return the wrong result or an error.

The solution is to use the block cipher directly, in this case sjcl.mode.cbc.
This also has the advantage of fewer format conversions - no converting to
base64 and JSON strings. This makes things faster. Also, it is actually correct
unlike the previous method.
Merge pull request #416 from ryanxcharles/bug/sjcl-failed-test

Solved: test vector that passes in node, but fails in browser/sjcl