Wallet polish

This took more effort than I thought it would. Nonetheless, this PR is more bark than bite - lots of tests, and some moving things around.

The wallet has switched to an 'unlimited addresses' model, though, if you exceed 2500 addresses for a single seed, you're not going to be able to do seed recovery. I don't think most people will get to that point.

The unlocking process has changed a lot. Now, you have to explicitly make a call to encrypt the wallet, instead of encryption happening on your first call to unlock.

The backup seed files are no longer used by the wallet. Instead, the wallet keeps everything in the settings file. The backup seed files are still created, and given a random suffix so that they don't obliterate existing seed files.

There's now an api call to backup the wallet, but no api call to load backups.

I tried my best, but I'm not super confident that the api spec matches the implementation. There are probably a few small things that slipped through.

I did change all PUT calls to POST calls, simply because I didn't want to deal with making PUT calls in go. I also changed /wallet/address from POST to GET, because you really are getting an address. It just is a lot more intuitive that way.

We're only doing halfway REST at this point. I think that's a good place to be. Our use cases is very different from the traditional REST model and we should break the rules a bit where it makes a ton of sense.

@Mingling94 this api implementation should fix some of the problems you were having with the UI. If you call /wallet/encrypt without supplying an encryption password (or supplying a blank one), then the seed that gets returned is not only the primary seed but also the encryption password. If you do supply a password during the encrypt process, then that password is what gets used as the encryption password.

Wallet has some key features missing still:

1. when recovering a seed or loading a file, there is no blockchain rescanning. Instead you'll need to restart the wallet. Crashes might actually happen if you don't. I'm not implementing this quite yet because I don't actually expect anyone to use the recover function in the near future.
2. No support yet for the old wallet files. I almost want to keep it this way too, as the old files are likely to add a lot of bloat. Maybe there can be some form of pruning for addresses that never got a transaction. That shouldn't be too hard to add on top of rescanning.
3. No way to load backup files that you've saved through the wallet.
4. No way to load keys that you made using siag, which means no siafund support as of this PR. Siafunds are supported for normal addresses, just not the siag multisig addresses.
5. Multisig spending is supported (though loading is not... lol), but it's not tested. The multisig spending needs to be tested.