Allow compiling bitcoind as a shared library: libbitcoind.so

We are all aware of alternative implementations of the bitcoin protocol. I've even helped personally implement [two][bcoin] of [them][bitcore]. There is an obvious fundamental problem with all alternative implementations that I'm sure everyone here sees: They're not bug-for-bug compatible with Satoshi's original implementation.

As we see more and more production platforms ([BitPay][bitpay], [Coinbase][coinbase], [Circle][circle], [Blockchain][blockchain], etc.) that _absolutely_ depend on the adamant stability of their platform, with __so__ much at stake, it is imperative that their backend protocol implementation be 100% compatible with the original protocol. That is non-trivial, and maybe even impossible to do with an alternative implementation.

Platforms and services like this are forced to use bitcoind as a backend on their servers if they want stability. Using just bitcoind with RPC calls has a number of limitations and hurdles.

- - -

This pull request alters the autoconf files to allow something like this:

``` bash
$ git clone git://github.com/bitcoin/bitcoin.git
$ cd bitcoin
$ ./autogen.sh
$ ./configure --enable-daemonlib
$ make
...
$ ls -la src/libbitcoind.so
```

Any program, or binding for a platform (python, php, node.js, ruby, etc), can now link to the official bitcoin implementation. Luckily bitcoind decided not to use `static` functions and put function templates in every header file, which means linkage to any function in bitcoind should be fairly easily as every function is exposed to the program which links to it.

## An Example

``` bash
# Write a program which links to libbitcoind
echo '#include "bitcoind.h"' > my_program.cc
echo '#include "..."' >> my_program.cc
echo 'extern bool AppInit(int, char **);' >> my_program.cc
echo 'int main(int argc, char **argv) {' >> my_program.cc
echo '  return AppInit(argc, argv) ? 0 : 1;' >> my_program.cc
echo '}' >> my_program.cc

# Compile our program
gcc -I$HOME/bitcoin/src -I$HOME/bitcoin/src/obj \
  -I$HOME/bitcoin/src/config -I$HOME/bitcoin/src/leveldb/include \
  -DHAVE_CONFIG_H -g -O2 -fexceptions -frtti -fpermissive \
  -o my_program my_program.cc \
  -lboost_system -lboost_filesystem -lboost_program_options \
  -lboost_thread -lboost_chrono -lssl -lcrypto \
  $HOME/bitcoin/src/libbitcoind.so

# Start our process
./my_program -server -daemon

# Bitcoind logs should be spitting out
tail -f ~/.bitcoin/debug.log
```

A contrived example: Obviously this capability would most likely be used to link to different platforms' modules/bindings with that binding being dynamically loaded into python's/node.js'/php's/ruby's memory.

### A More Complete Example

At BitPay, I have written a fully fledged node.js binding which links to `libbitcoind.so` and can do almost anything an alternative bitcoin implementation can do. It is called [bitcoind.js][bitcoindjs].

Feel free to examine the [documentation][doc] and [source][cc] to see the actual [benefits][js] something like this would provide.

## What this PR does:

- Moves `main()` out of `bitcoind.cpp` and into `bitcoind_main.cpp`. Moves all includes and variables out of `bitcoind.cpp` and into `bitcoind.h` so it can be included by both `bitcoind.cpp` and `bitcoind_main.cpp` if necessary.

- Exposes two or three functions in header files which will be useful for different platforms linking to libbitcoind. This required creating an `rpcwallet.h` header file.

- Adds `--enable-daemonlib` argument to `configure.ac` - this enables `-fPIC` for all object files instead of -`fPIE`. It also sets an AM conditional which is checked for in the automake file. Also resets `-fvisibility` to its default.

- When compiling the library, automake makes use of this `AM_CONDITIONAL` such that targets are overridden by one `all:` target compiling the library, and bitcoin-qt(+tests) is ignored.

- Now that all object files can be compiled as position independent code, the custom `Makefile` target I've added (vanilla Make syntax - I'm sure automake can do something fancier and compile a shared object through the help of libtool, but I couldn't manage to make it work) can link these object files together into `libbitcoind.so` with `-shared -fPIC`.

## Issues and potential annoyances:

I figure I'll address these since I'm fairly certain these questions will be raised.

- If you want to compile bitcoind or bitcoin-qt, the object files compiled for libbitcoind are essentially useless since they're not `-fPIE`. You have to clean and recompile for scratch.

- Since bitcoind was never structured like a proper library, it's essentially one big mess: there is logging and arg parsing all over the place. A coder's best bet is to write their own stripped down version of `AppInit2()` which starts up the net.cpp threads and listens for `RequestShutdown`, eventually joining all threads. Currently, bitcoind.js simply starts up `AppInit2()` on a separate thread.

- Name Mangling: Node.js module bindings are written in C++. Lua and Ruby bindings are canonically written in C, which means in order to use libbitcoind without guessing bizarre function names, functions will have to be exposed with `extern "C"` on non-OO functions to force the stopping of mangled names. Of course, the workaround would be for Lua and Ruby users to write a C++ wapper and then link to them from their C binding.

- Internal API: When I first started writing bitcoind.js, I forked bitcoin v0.9.0 and turned it into a shared library. Once I rebased it onto the latest master, a lot of functions had changed and took differen params, a lot of classes were changed or added. I had to rewrite several functions. Any program depending on libbitcoind.so will have to deal with this as bitcoind is developed since it is not developed like a library.

- The Build: I'm sure there's a slicker way to compile this as an `.so`. I'm really not an Automake guru. I've fooled around a bit with the build here, but at the end of the day, someone smarter than me could probably do a better job at writing a `src/Makefile.daemon.include`.

  The `noinst_LIBRARIES` libraries and other magical features of automake are simply ignored when `--enable-daemonlib` is used. The .mm.o target compiles all the object files necessary to link them up into a shared library with a vanilla make target.

- Platforms: I'm not terribly familiar with OSX, but right now, I've only tested this build on Linux (Arch). I've had two friends try to build on OSX with unfortunate results that were apparently common in trying to compile bitcoind on OSX. I'm still unsure if this will work with Macintoshes. I have even less of an idea of how windows works compared to OSX.  Maybe it could be made into a `.dll` somehow.

## The Score

There may be better ways of doing this, but I think if the future of bitcoin and the bitcoin world is to be a bright one, bitcoind _needs_ to be reshaped into an optional library in some form. I don't only speak on behalf of my employer here ([BitPay][bitpay]), even though I'm sure we all agree. This also happens to be my personal opinion on the matter.

I open this to discussion. I'm willing to do whatever it takes to make Bitcoin into a library.

[bcoin]: https://github.com/indutny/bcoin
[bitcore]: https://github.com/bitpay/bitcore
[bitcoindjs]: https://github.com/bitpay/bitcoind.js
[bitpay]: https://bitpay.com/
[coinbase]: https://www.coinbase.com/
[circle]: https://www.circle.com/
[blockchain]: https://blockchain.info/
[bindinggyp]: https://github.com/bitpay/bitcoind.js/blob/master/binding.gyp#L31
[doc]: https://github.com/bitpay/bitcoind.js/blob/master/README.md#documentation
[js]: https://github.com/bitpay/bitcoind.js/blob/master/lib/bitcoind.js
[cc]: https://github.com/bitpay/bitcoind.js/blob/master/src/bitcoindjs.cc
Nit: Year and just MIT license.