feat(access-token2): support multiple services of the same type

[sunshinexcode]

Summary

Update AccessToken2/Token007 implementations to support multiple services in one token, including multiple services with the same ServiceType.

Changes

• Preserve multiple services with the same ServiceType instead of overwriting them.
• Pack services in stable ServiceType order while preserving insertion order for duplicate types.
• Stop safely when parsing an unknown ServiceType and retain previously parsed known services.
• Verify signatures using the original signing payload, independent of parsed services.
• Reject token generation when no service is present.
• Keep high-level token builder method signatures unchanged.
• Standardize the Dart Token007 implementation and add missing service builders and samples.
• Improve parse.py output for multi-service tokens.
• Add Docker-based test, coverage, and sample targets for all languages.

Languages

• C++
• C#
• Dart
• Deno
• Go
• Java
• Lua
• Node.js
• PHP
• Python 2
• Python 3
• Ruby
• Rust

Compatibility

• Tokens generated by the previous version can be parsed and verified by the new version.
• New tokens containing only known, non-repeated ServiceTypes remain compatible with old parsers.
• Old parsers do not support repeated or unknown ServiceTypes:
  • C# may fail parsing duplicate ServiceTypes.
  • Other old implementations may retain only one duplicate service.
  • Unknown ServiceTypes may cause parsing failures or exceptions.
• Consumers that parse tokens must upgrade before receiving repeated or newly added ServiceTypes.
• High-level builder APIs remain unchanged. Low-level callers that directly access service containers may require migration from map/dictionary access to GetServices or equivalent APIs.

Testing

• Ran all language unit tests with coverage:

  make test

• Covered:

  • Existing Token007 parsing and signature verification
  • Multiple distinct ServiceTypes
  • Repeated ServiceTypes
  • Stable ServiceType ordering
  • Unknown ServiceTypes before and after known services
  • Empty-service token rejection
  • Cross-version generation and parsing

• parse.py successfully parsed all old and new compatibility cases, including repeated services and unknown ServiceTypes.

Integration Note

The current public RTC/RTM Web Demo accepts old tokens and new tokens without repeated ServiceTypes.

A token containing RTC + RTC + RTM currently fails on the deployed demo chain:

• RTC: NO_AUTHORIZED
• RTM Web SDK 1.4.5-222: Signature verification failed

The token passes parsing and signature verification with the updated local library. RTC/RTM SDK and server-side token parsers must be upgraded before repeated-ServiceType tokens are enabled in production.