feat: add token snapshot mechanism for governance voting and airdrops

[AugistineCreates]

This pr closes #163

Problem
Governance proposals and airdrop campaigns need to consider token holdings at a specific point in time. Without a historical balance record, voting power and airdrop eligibility can be distorted by transfers that occur after the snapshot moment, leading to unfair outcomes.

Solution
Added a full snapshot system to the token contract:

• Snapshot creation – create_snapshot() records the balances of all token holders at the current ledger height, stores the data under a snapshot ID, and emits a snapshot_created event.
• Historical balance query – balance_at_snapshot(address, snapshot_id) returns the balance of any address for a given snapshot.
• Storage limits – Only a configurable number of active snapshots (max 10) are kept; older snapshots are automatically pruned to bound storage costs.
• Integration – The token’s write_balance now registers each address as a holder so that snapshots always include every participant.
• SDK exposure – Added createSnapshot and getBalanceAtSnapshot methods to the client SDK so applications can trigger snapshots and query historic balances easily.
• Testing – New unit test test_snapshot_mechanism exercises multi‑transfer scenarios, verifies balances at multiple snapshots, and confirms that the oldest snapshot is removed when the limit is exceeded.

Outcome
The contract now supports fair governance voting and retroactive airdrops based on immutable historical balances, while keeping storage usage predictable.

[drips-wave]

@AugistineCreates 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