Feature Request: SignalR Protocol Binding

## Description

I'd like to propose adding support for ASP.NET Core SignalR through a dedicated AsyncAPI binding specification.

SignalR is a widely adopted real-time communication framework in the .NET ecosystem. While SignalR commonly uses WebSockets as a transport, it introduces higher-level concepts that are not represented by existing WebSocket bindings, including:

* Hubs
* Client-to-server method invocation
* Server-to-client method invocation
* Streaming
* Groups
* User-targeted messaging
* Negotiation and transport fallback

Because of these concepts, documenting SignalR APIs using generic WebSocket bindings loses important semantic information that code generators and documentation tools could otherwise leverage.

## Motivation

Many organizations use AsyncAPI to document event-driven and real-time systems. SignalR applications currently require custom extensions or incomplete WebSocket representations.

A dedicated SignalR binding could:

* Improve documentation quality
* Enable code generation for SignalR clients and servers
* Standardize SignalR API descriptions across projects
* Better represent hub-based communication patterns

## Initial Ideas

A SignalR binding might include metadata such as:

* Hub name
* Target method
* Invocation type
* Streaming configuration
* Group messaging semantics
* User-targeted delivery semantics

Example:

```yaml
channels:
notifications:
bindings:
signalr:
hub: NotificationsHub
target: ReceiveNotification
```

Or alternatively at the operation level:

```yaml
operations:
sendMessage:
action: send
bindings:
signalr:
hub: ChatHub
method: SendMessage
```

## Questions

* Would SignalR fit better as a dedicated protocol binding or as an extension of the existing WebSocket binding?
* Are there existing binding design patterns that would be appropriate for hub-based communication frameworks?
* Is there community interest in collaborating on a formal proposal (AIP)?

I'd be happy to contribute a draft specification if the maintainers believe this aligns with the AsyncAPI roadmap.

Start by reviewing the existing AsyncAPI protocol binding specifications and patterns for WebSocket-based protocols. Compare those conventions with the SignalR concepts listed in the issue, then determine whether a dedicated binding or extension is appropriate. Done would be a maintainer-approved formal proposal with a defined scope and specification structure.

Written by the indexing model from the issue text.