CIP-102 implementation (builds on #297 & #490)

[SamDelaney]

Add CIP-102 (Royalty Datum Metadata) support

This PR is dependent on the work done in #490 - specifically, CIP-102 makes use of CIP-67 asset names. It can either be reviewed & merged independently as an combined PR for CIPs 67, 68 & 102, or it can be merged after #490 / #297 is merged.

• Added cip102.py implementing the CIP-102 Royalty Datum Metadata standard
  • CIP102RoyaltyTokenName: Subclasses CIP67TokenName (label 500) to represent royalty token asset names. Supports an optional integer postfix for version-2 multi-recipient policies (e.g. (500)Royalty, (500)Royalty1, (500)Royalty2)
  • RoyaltyRecipient: Plutus constructor 121 encoding a single recipient's address (raw Plutus address bytes), fee denominator (floor(10 / pct * 10)), and optional min/max fee bounds (each encoded as optional_big_int using constructors 121/122)
  • RoyaltyInfo: Top-level datum (Plutus constructor 121) wrapping a list of RoyaltyRecipients, a version field, and an extensible extra field — serializes directly to inline datum CBOR
  • RoyaltyRecipientSomeMinFee / RoyaltyRecipientNoMinFee: Internal Plutus Some/None types for optional integer fields; follows the same optional_big_int CDDL shape as the spec
• Added test_cip102.py with 29 unit tests covering token name construction, CBOR round-trips, recipient construction with/without optional fees, version 1 vs. version 2 semantics, and fee percentage validation
• Updated init.py to export all CIP-102 symbols alongside existing CIPs