Cardano Updates

It's no longer necessary to worry about exporting the default
constructor for `TokenMap`.

The original concern was that exporting the default constructor would
allow callers to break the invariant that there are no `mempty` values
in the map.

However, this is no longer possible, as the `MonoidMap` type handles
this invariant automatically.

Therefore, it's no longer necessary to have a warning.

Nevertheless, this commit doesn't export the default constructor, as
there currently isn't any need to do so.

The `TokenMap` type has an invariant that:
- no `mempty` values appear within the internal data structure.
- no `mempty` values appear within any encoding of a `TokenMap`.

The `MonoidMap` type already guarantees to handle this invariant, and that
type is covered by a comprehensive test suite.

Therefore, there's no need to repeat those tests for the `TokenMap`
type.

3862: Make API error expectations compiler-checkable. r=jonathanknowles a=jonathanknowles

Follow-on from https://github.com/input-output-hk/cardano-wallet/pull/3824 ([ADP-2269](https://input-output.atlassian.net/browse/ADP-2269)).

## Summary

This PR replaces `expectErrorCode`, which creates expectations based on string comparisons, with `expectErrorInfo`, which creates expectations based on `ApiErrorInfo` objects.

This has two advantages:
- expectation expressions can be checked statically by the compiler.
- it's possible to express richer expectations based on internal fields of errors (not all errors are just simple values -- some have nested records), using combinators provided by `hspec`.

## Context

In our test suite we test at least two kinds of mapping:

- The mapping between API types and their serialised JSON representations: for all API types, the JSON encoding should be consistent with the OpenAPI specification, and the round trip property `(decode . encode == id)` should hold for all values.
- The mapping from (API call, inputs, state) to API response values: i.e, that API calls return the responses we expect, given appropriate inputs and the current (implicit) wallet state.

Up until now, the approach we've used in `cardano-wallet` is to separate the above two concerns into **different test suites**, i.e., to:

- test expectations about our JSON serialisation logic in specialised tests for just that purpose (JSON golden round trip tests and the test suite for the OpenAPI spec).
- within other test suites (such as the integration test suite), **assume** the correctness of our JSON serialisation logic, and express expectations in terms of ordinary (decoded) Haskell values.

API errors have, up until now, been a sort of exception to this separation of concerns, because until recently we didn't have a good way to create structured errors.

But since merging #3557, which provides support for structured errors and the accompanying [decodeErrorInfo](https://github.com/input-output-hk/cardano-wallet/blob/504774f0f08f4ec74fa91106bc004d8e7b97f875/lib/wallet/integration/src/Test/Integration/Framework/DSL.hs#L559) function, we've gradually been converting expectations about API errors to use the same style as we use for ordinary values returned by the API, which is to express expectations in terms of ordinary Haskell expressions, and to avoid writing expectations in terms of hard-coded strings.

For example, for ordinary (non-error) API responses, we typically write expectations like this:
https://github.com/input-output-hk/cardano-wallet/blob/7af6d54d21443146320eab04452eefb75b3d553e/lib/wallet/integration/src/Test/Integration/Scenario/API/Shelley/Transactions.hs#L297-L299

Co-authored-by: Jonathan Knowles <[email protected]>