[EVM/AAL] Fixed a bug in the vout limit checking that caused problems when the number of outputs in a transaction is greater than 256

Work completed:

[Documentation] Updated the issue template on github

[EVM/AAL] Changed the vector for tracking "deleted addresses" to be a set, which resulted in a major performance boost in the AAL's Condensing Tx generation

[Staker/Wallet] Added ability to unlock the wallet for staking only

[EVM/AAL] Changed how the contract vout limit checking was implemented to be faster and have a more reasonable security profile

[Tests] Fixed failing QA tests due to changing the coin maturity to 500 for testnet-1 parameters

[Documentation] Added guide for how to participate in the Sparknet/testnet-1

[Documentation] Added instructions for building on OSX

[Tests] Fixed failing tests caused by switching to a new contract address format

[Consensus/EVM] Made it so that coinbase in Solidity returns the 2nd vout of the 2nd tx in a PoS block - This breaks consensus and was only merged to master

[RPC] Added new commands to convert base58 addresses to and from the hex addresses used in the EVM

[RPC] Added a sendmanywithdupes RPC call which is like sendmany but can send more than 1 output to a single address in a single transaction

[Documentation] Cleaned up changelog to remove old Bitcoin releases

[Documentation] Add instructions for compiling Qtum on Ubuntu 14.04

[Misc] Fixed some minor code syntax to allow building on older GCC compilers (part of building on Ubuntu 14.04)

[Misc] Refactored code so that it is more easily possible to access the Version field of a contract creation/call transaction

[Testing] We have been testing and reviewing the DGP implementation

[Consensus/EVM] Updated the EVM to allow a sender that is 0 (before it threw an exception). This is a minor consensus break that will be merged into testnet-1

In-progress work and soon to be fixed bugs:

[Misc] I (earlz) have been doing some prototyping on Qtum to add a 32bit x86 VM to Qtum. This would allow for writing contracts in C, C++, Rust, etc. Anything that supports x86. It should be complete for prototype purposes next week and will be accompanied by a blog post etc, covering what exactly that means. This does not mean that Qtum will be officially supporting x86 contracts in the future, this prototyping is to help us determine if it is a good idea, and it would most likely not happen until after the mainnet release if we were to support it.