feat: Add Neo3 module with official RPC methods only

[apisit]

• Add comprehensive Neo3 module (spoon_toolkits/crypto/neo3/)

  • 22 tools covering all official Neo N3 RPC methods
  • Organized into 6 categories: Block, Transaction, NEP, Contract, Governance, Utility
  • Neo3Provider for direct RPC access
  • Full async/await support

• Add comprehensive test suite (tests/crypto/neo3/)

  • Dedicated test file for each tool module
  • Tests for all 22 tools
  • Address info tests including unclaimed gas

• Update main README.md

  • Add Neo3 module documentation section
  • Add usage examples
  • Update multi-chain support section

This module exclusively uses official Neo N3 RPC methods as documented at developers.neo.org, ensuring 100% compatibility with any Neo N3 RPC node.

[helloissariel]

The Neo3 tools in this PR are direct wrappers around the official Neo N3 node standard RPC interfaces.
The crypto/neo tools we built earlier are based on the JSON-RPC API provided by Neofura, which offers a wider and richer set of tools.Only a small number of tools exist in Neo N3 but not in Neofura.I think there will be quite a lot of overlapping / duplicated tools between this Neo3 module and the existing crypto/neo (Neofura-based) tools.You can refer to https://neofura-1.gitbook.io/api-docs/reference/json-rpc-requests.

[apisit]

Thank you for the feedback! You're absolutely right that there's overlap between the crypto/neo (Neofura-based) tools and this new crypto/neo3 module. Let me clarify the design rationale:

The crypto/neo3 module is intentionally built to use only official Neo N3 RPC methods for the following reasons:

1. Universal Compatibility: Tools should work with any Neo N3 RPC node (self-hosted, public nodes, etc.) without requiring third-party services
2. Reduced Dependencies: No reliance on external APIs or explorer services that may have rate limits, downtime, or access restrictions
3. Clear Boundaries: Users can distinguish between standard RPC methods (always available) and enhanced methods (service-specific)

I agree that having both Neofura-based tools and official RPC tools in the same package can be confusing. Here's my proposal:

Option 1: Separate Package (Recommended)

• Move Neofura-dependent methods to a separate package (e.g., spoon_toolkits/data_platforms/neofura/)
• Keep crypto/neo3 for official RPC methods only
• This makes the dependency explicit and allows users to choose based on their needs

Option 2: Clear Documentation

• Keep both but clearly document which methods require Neofura vs. standard RPC
• Add deprecation notices for Neofura-specific methods in crypto/neo that overlap with official RPC

Benefits of This Approach
For users who need Neofura features: they can use the Neofura package for richer data
For users who need portability: they can use crypto/neo3 with any RPC node
For the ecosystem: clear separation of concerns and explicit dependencies
Would you prefer Option 1 (separate package) or Option 2 (documentation)?