Don't create empty transactions when reading corrupted wallet

The current transaction loading code is not exception safe.
An exception during deserialization causes an empty transaction
to be left behind in the wallet.

Fix this by building the transaction separately and adding
it only to the wallet at the end.

Fixes #3333.
src/leveldb/Makefile is ignored?

remove the "-" in leveldb-* to include src/leveldb/Makefile
qt: use series of pngs for spinner

Use a series of .png frames for the spinner instead of a .mng.
`mng` is an obscure image format and is not built by default into Qt5.

This appears to improve the crispness of the spinner as well.

Does not noticably increase the size (still ~27k) and the code
is not more complicated either.
Merge pull request #3525

15570cc src/leveldb/Makefile is ignored? (harry)
Merge pull request #3526

f10b2d7 qt: use series of pngs for spinner (Wladimir J. van der Laan)
qt: Update copyright year in about dialog to 2014
qt: Update remaining "The Bitcoin Core Developers"
update copyright year to 2014
[Qt] add missing lock in walletmodel
[Qt] 2 minor translation changes
Merge pull request #3537

8c20bbb update copyright year to 2014 (Philip Kaufmann)
[Qt] small paymentserver header cleanup
Merge pull request #3540

57d8e3f [Qt] add missing lock in walletmodel (Cozz Lovan)
Merge pull request #3541

c704532 [Qt] small paymentserver header cleanup (Philip Kaufmann)
Merge pull request #3538

81bad8b [Qt] 2 minor translation changes (Philip Kaufmann)
Merge pull request #3426

16ec904 Don't create empty transactions when reading corrupted wallet (Wladimir J. van der Laan)
Move only: extract WriteChainState and UpdatedTip from SetBestChain.
Prepare block connection logic for headers-first.

This changes the block processing logic from "try to atomically switch
to a new block" to a continuous "(dis)connect a block, aiming for the
assumed best chain".

This means the smallest atomic operations on the chainstate become
individual block connections or disconnections, instead of entire
reorganizations. It may mean that we try to reorganize to one block,
fail, and rereorganize again to the old block. This is slower, but
doesn't require unbounded RAM.

It also means that a ConnectBlock which fails may be no longer called
from the ProcessBlock which knows which node sent it. To deal with that,
a mapBlockSource is kept, and invalid blocks cause asynchronous "reject"
messages and banning (if necessary).
Per-peer block download tracking and stalled download detection.

Keep track of which block is being requested (and to be requested) from
each peer, and limit the number of blocks in-flight per peer. In addition,
detect stalled downloads, and disconnect if they persist for too long.

This means blocks are never requested twice, and should eliminate duplicate
downloads during synchronization.
Limit the number of orphan blocks

In case the total number of orphan blocks in memory exceeds a limit
(currently set to 750), a random orphan block (which is not
depended on by another orphan block) is dropped. This means it will
need to be downloaded again, but it won't consume memory until then.