Report proposal errors earlier and more precisely where possible

[daira]

This follow-up to #1257 is not essential, but it improves the error reporting by:

• reporting some errors when a proposal is constructed rather than when it is used to create transactions;
• reporting more precise errors for unsupported operations.

[codecov]

Codecov Report

Attention: Patch coverage is 32.60870% with 31 lines in your changes missing coverage. Please review.

Project coverage is 60.67%. Comparing base (f35a894) to head (46f1e7b).

Files	Patch %	Lines
zcash_client_backend/src/proposal.rs	31.25%	22 Missing ⚠️
zcash_client_backend/src/data_api/error.rs	25.00%	6 Missing ⚠️
zcash_client_backend/src/data_api/wallet.rs	0.00%	2 Missing ⚠️
zcash_client_backend/src/fees.rs	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1441      +/-   ##
==========================================
- Coverage   60.73%   60.67%   -0.06%     
==========================================
  Files         140      140              
  Lines       16467    16475       +8     
==========================================
- Hits        10001     9996       -5     
- Misses       6466     6479      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[daira]

This is not up-to-date with #1257. I will rebase it when that merges.

This is now rebased onto main.

[nuttycom]

Flushing comments.

[nuttycom]

I'm not sure that having two different variants that wrap ProposalError is a good idea; it suggests that the entire state space of ProposalError is reachable by multiple paths, but the comment here suggests something different, and that only a subset of ProposalError is reachable via the path that produces ProposalNotSupported.

[nuttycom]

Should these variants really be a part of ProposalError?