Mining bugfix: Properly initialize g_best_block at startup

Summary
---

This MR fixes the bug in issue Bitcoin-ABC#189.  The global variable `g_best_block`
was not properly initialized at app startup.  It would get initialized
later after a new block arrives from the network, however.

This is a bug affecting Core, BCHN and ABC.  BU does not have this bug.

More background, from issue Bitcoin-ABC#189: It was observed that when using the
`longpoll` version of `getblocktemplate`, and if the node was freshly
started, that the node would return results right away.  The longpoll
spec says that if the client provided a longpoll id, the node should
wait until a new block has arrived, or until 60 seconds have elapsed
*and* there are new transactions. This was not happening here.

The reason? `g_best_block` was uninitialized!

This MR ensures that `g_best_block` is initialized and is not `0000.000`
at app start, if we have a chain tip. Thus the invariant is guaranteed
and no bugs on first run.

Test Plan
---

- `ninja check all`
- Also if @ago is around -- please try this branch and ensure it fixes the
  observed bug.

src/init.cpp

@@ -2615,6 +2615,14 @@ bool AppInitMain(Config &config, RPCServer &rpcServer,
 
     // Step 12: start node
 
+    //// Ensure g_best_block (used by mining RPC) is initialized
+    {
+        LOCK2(cs_main, g_best_block_mutex);
+        if (auto *tip = ::ChainActive().Tip()) {
+            g_best_block = tip->GetBlockHash();
+        }
+    }
+
     int chain_active_height;
 
     //// debug print