[#248] Avoid redundant calls to octez-client address store

Description

This introduces a type AddressWithAlias and uses it in the code paths where both are required. Key generation functions also now return AddressWithAlias for convenience.

A new class ToImplicitAddress is introduced in Cleveland to simplify working with AddressWithAlias in context where an address would be expected.

Types of functions in Morley.Client.TezosClient.Impl were changed to avoid calls to getAlias/resolveAddress.

I didn't yet add tests to count how many calls to getAlias/resolveAdddress we get now for a typical operation like transfer or origination, but a quick look at cleveland verbose log says it's a lot less.

For now, I want to see if I broke much and if there's any noticeable speed-up in running network tests (probably not, but who knows).

Apparently there is a bit of a speed-up (old runtime taken from a recent job for another MR):

local-chain test	old runtime (minutes)	new runtime (minutes)
morley-client	5:37	4:55
cleveland	18:54	14:26
morley	13:34	11:54
lorentz	10:54	8:01

Some of that might be due to run-to-run differences in local-chain performance, but numbers are consistently measurably lower, so that's at least a small win.

Side note: reading from tezos-client store directly would be faster than calling octez-client, but there are a lot of edge cases to worry about there, and there's a non-negligible chance that upstream will change some details in the near future, with the rename to octez-client and all. So this I find to be a more robust approach: just reduce the number of calls. One call is cheap compared to network wait time, we only have an issue when each network operation incurs many calls to octez-client to convert between addresses and aliases, and this was indeed the case.

Related issue(s)

Resolves #248 (closed) (although not necessarily in a way it was intended), also happens to resolve #894 (closed)

✅ Checklist for your Merge Request

Related changes (conditional)

• Tests (see short guidelines)

  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.

• Documentation

  • I checked whether I should update the docs and did so if necessary:
    • Root README and other README.md files
    • Haddock
    • docs/
  • I updated changelog files of all affected packages released to Hackage if my changes are externally visible.

Stylistic guide (mandatory)

• My commits comply with the following policy.
• My code complies with the style guide.