Consistent custom attributes for HELLO + separate tests set

[vovchisko]

Description, Motivation and Context

This PR implements consistent custom attributes validation across all WAMP message types according to WAMP specification 3.1. Previously, the HELLO message used helloCustomDetails, which accepted any attributes without validation, while other messages used _extractCustomOptions with proper regex validation (^_[a-z0-9_]{3,}$).

Bugfix

• Fixed missing retain option on publish.

The change ensures all WAMP message types follow the same validation pattern for custom attributes, improving consistency and spec compliance.

What is the current behavior?

• HELLO.Details accepts any custom attributes without validation via helloCustomDetails
• Other message types (SUBSCRIBE.Options, PUBLISH.Options, CALL.Options, etc.) use _extractCustomOptions with proper regex validation
• Inconsistent behavior across message types for custom attributes handling

What is the new behavior?

• All WAMP message types now use consistent _extractCustomOptions validation
• HELLO.Details now properly validates custom attributes using the same ^_[a-z0-9_]{3,}$ pattern
• Invalid custom attributes are silently filtered out (not passed to router)
• Comprehensive test suite added covering all 16 WAMP message types

What kind of change does this PR introduce?

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (no new functionality, only code improvements)

Checklist:

• My code follows the code style of this project.
• I have added tests to cover my changes.
• Overall test coverage is not decreased.
• All new and existing tests passed.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[KSDaemon]

Okay. Thnx for removing some AI-garbage....
But I still don't see how customOptions are tested....
If they are not passed or are not correctly processed - then there will be no data-matching and default response for msg type will be returned. That's it. Where does the actual test happen?