docs: CONTRIBUTING guide section on adding invoice options (#703)

[christy-dev4]

Add "Adding Invoice Options" section to CONTRIBUTING.md

Summary

Closes #703

This PR adds a new "Adding Invoice Options" section to CONTRIBUTING.md
that documents, for new contributors, exactly how to extend the invoice option
surface without breaking Soroban's #[contracttype] field limits or the
on-chain storage layout.

The section was written after reading the actual storage types
(InvoiceOptions, InvoiceOptions2, InvoiceCore, InvoiceExt,
InvoiceExt2, InvoiceExt3 in contracts/split/src/types.rs) and the
migration framework (contracts/split/src/migrations.rs), so the guidance
matches the code rather than guesses at it.

Acceptance Criteria mapping

Criterion	Where it is addressed
New section "Adding Invoice Options" added to CONTRIBUTING.md	New ## Adding a new invoice option field section
Explains the 40-field #[contracttype] constraint and the InvoiceOptions / InvoiceOptions2 split	"The 40-field #[contracttype] constraint" subsection
Explains the InvoiceCore / InvoiceExt / InvoiceExt2 storage split and when to use each	Storage-split table + rule of thumb
Includes a numbered checklist for adding a new field end-to-end	"End-to-end checklist for adding a new field" (8 steps)
Notes that storage schema changes require a migration entry	Step 6 of the checklist + explicit MigrationRequired warning

What the new section covers

1. Field-limit rule. Soroban #[contracttype] structs cap at 40 fields;
   InvoiceOptions sits at/near that ceiling and InvoiceOptions2 is the
   overflow bucket. New optional fields go to InvoiceOptions only when it has
   room, otherwise to InvoiceOptions2. Order/offsets are part of the on-chain
   XDR layout, so existing fields must never be reordered or deleted to make room.
2. Storage split. A table explains InvoiceCore (hot-path always-present
   facts), InvoiceExt (default home for optional behavior), InvoiceExt2
   (dispute/auction/oracle/overflow extension state), and InvoiceExt3 (newest
   bucket), with a rule of thumb that optional fields belong in the Ext
   structs, not InvoiceCore.
3. End-to-end checklist. Add to input struct → add matching persisted field
   → wire the copy in create_invoice + default constructors → thread through
   reads/updates → update STORAGE_KEY_REGISTRY.md if a new key is introduced →
   bump CURRENT_SCHEMA_VERSION and add a migration_vN → tests → docs.
4. Before/After example showing a new mint_receipts option added to
   InvoiceOptions2, mirrored into InvoiceExt2, copied at creation, defaulted,
   and covered by a migration + tests.

Testing

This is a documentation-only change; no contract code is modified, so
cargo test behavior is unchanged. I verified the file renders correctly and
the new anchors/links point at real paths in the repo.

cargo fmt --check   # docs-only; no Rust changes

Notes for reviewers

• The section intentionally references InvoiceExt3 even though issue Add CONTRIBUTING guide section on how to add new invoice options #703
  only named InvoiceCore / InvoiceExt / InvoiceExt2, because the file
  actually defines InvoiceExt3 (types.rs:1475) and contributors will hit it
  in practice.
• The migration step (step 6) is the part new contributors most often miss; it
  is called out prominently because a missed schema bump makes every entry point
  panic with MigrationRequired on already-deployed contracts.

closes #703

[drips-wave]

@christy-dev4 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits