Use pruneheight instead of hammering getblock

[Sjors]

When starting a new lightning node that's connected to a pruned bitcoind node, I get a flood of log messages like:

2018-03-27T10:29:59.549Z lightningd(12118): bitcoin-cli getblock 000000000000000000075750b9d433983830f4560044e4977b10b100668e6509? exited with status 1

This seems to go on for quite a while. I can't tell if it's going in circles or fetching blocks in random order.

It would seem more efficient to call getblockchaininfo, check if pruned is true and then use pruneheight to know which blocks not to ask for.

[cdecker]

This will be easily fixed by not going back to the wallet birth blockheight. We're working on that, but onchaind is proving a bit hard to modify to this new paradigm. Since the cause and fix are the same I'm marking this as a duplicate of #1179