zebra: Use the same format as `zcashd` for `getblocktemplate` proposal mode errors

Motivation

When I use zebra-utils/zcash-rpc-block-template-to-proposal from PR #5944 to send a block proposal from Zebra to both zcashd and Zebra, I see these differences in the response format:

Proposal response diffs between ports  8232 6666 and time sources CurTime MinTime MaxTime ClampedNow:
--- /tmp/tmp.UWcAoSvcUZ.block-template-proposal/proposal-check-getblocktemplate-proposal.CurTime.8232.json	2023-01-26 15:15:37.881314992 -0300
+++ /tmp/tmp.UWcAoSvcUZ.block-template-proposal/proposal-check-getblocktemplate-proposal.MaxTime.6666.json	2023-01-26 15:15:38.329290891 -0300
@@ -0,0 +1,5 @@
+invalid proposal: Block {
+    source: ValidateProposal(
+        "proposal is not based on the current best chain tip: previous block hash must be the best chain tip",
+    ),
+}

Zebra should return a string to match the zcashd response format, but it is currently returning JSON. For example zcashd returns errors like bad-txns-inputs-missingorspent

Specifications

We were following the specifications in the bitcoin improvement proposals here, but being compatible with the zcashd implementation is a higher priority.

It is enough to return any error string in kebab-case format - we don’t need to match the exact error wording.

For the example above about best tip error zebra should return something like:

invalid-proposal-proposal-is-not-based-on-the-current-best-chain-tip-previous-block-hash–must–be-the–best-chain-tip

Complex Code or Requirements

This should be a simple format change.

Testing

We can use the zebra-utils/zcash-rpc-block-template-to-proposal script to manually re-test to make sure this bug is gone. We’ll need to wait for an error.

(The previous block error happens if a new block has just arrived, or there is a chain fork.)