Refactor - Addresses

[DaMatrix]

Description

This PR depends on #47 (bincode-2), #45 (crypto), and #41 (macros).

This adds new struct types specific to each kind of address. This brings three major advantages:

• Type-safety for all code interacting with addresses
  • Has the added benefit of forcing all address objects to contain a valid address, whereas before there was no guarantee that the arbitrary Strings representing addresses were actually valid addresses
  • Prevents invalid operations, such as using a P2SH address for P2PKH verification
• Improved performance: the address types all wrap fixed-length byte arrays, they cause no additional heap allocations and can be copied using just 2-4 instructions
• Compact binary serialization using Bincode 2

Additionally, by representing transaction output addresses as an enum between different address types, we can infer the output's locking script based on the address type. This is much cleaner than the mechanism used in Bitcoin, which actually includes the full script but then has to do pattern matching to determine which of the small number of supported transactions it actually is. More locking script formats can be added in the future by simply adding more address variants!

These types are not actually used yet, but will be in subsequent PRs.

Changelog

• Added struct types for P2PKH and P2SH addresses, as well as the "address" (really just the TxIns hash) used in DRUID expectations
• Added an enum for differentiating the "real" address types which can occur in a transaction output

Type of Change

Please mark the appropriate option by putting an "x" inside the brackets:

• Bug fix
• New feature
• Enhancement or optimization
• Documentation update
• Other (please specify)

Checklist

Put an "x" in the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!

• I have tested the changes locally and they work as expected.
• I have added necessary documentation or updated existing documentation.
• My code follows the project's coding standards and style guidelines.
• I have added/updated relevant tests to ensure the changes are properly covered.
• I have checked for and resolved any merge conflicts.
• My commits have clear and descriptive messages.

Screenshots (if applicable)

If the changes affect the UI or have visual effects, please provide screenshots or GIFs showcasing the changes.

Additional Context (if applicable)

Add any additional context or information about the changes that may be helpful in understanding the pull request.

Related Issues (if applicable)

If this pull request is related to any existing issues, please list them here.

Requested Reviewers

Mention any specific individuals or teams you would like to request a review from.

[BHouwens]

Looks great to me. This one will require very careful compatibility handling in Network, as it directly touches the API with "unclean" client data