Remove reflection from general and Azure Service Bus-specific message routing

[stijnmoreels]

Discussed in #261

^{Originally posted by fgheysels March 24, 2022}
Not an idea for a new feature, but an idea for a possible improvement.
As mentionned in this PR #260 , the code to retrieve registered IMessageHandler implementations is not that stable. We should find a way to improve this.

@stijnmoreels's comment copied from the mentionned PR:

You'll probably wonder why we have this reflection code in the MessageHandler file.
This is bc we were faced with a problem when implementing the message routing. The IServceProvider doesn't support open generic interfaces and since our IMessageHandler<,> is such an open interface, there is no build-in way to extract all service registrations with a generic message type.
This message handler class will do this for us. It searches for the 'engine' and 'call site factory' on the service provider and extracts all the message handler interfaces. Later on, we can determine if there exists and message handler that can process the incoming message.

We can off course discuss this later, or come up with something else. For now, this was the best we could do. Unfortunately.

I was wondering if we couldn't work around this without using reflection.
Maybe it is an idea to introduce a non-generic interface (empty) IMessageHandler. The IMessageHandler<,> would then derive from that non-generic IMessageHandler interface, like this:

public interface IMessageHandler 
{
}

public interface IMessageHandler<in TMessage, in TMessageContext> : IMessageHandler where TMessageContext : MessageContext
{
     ...
}

The code for retrieving registered message-handlers could then work on retrieving types that are assignable from the base-interface IMessageHandler.
Once we have retrieved those types, then we need of course an additional filter: we only want to take into consideration those types that are also assignable to the IMessageHandler interface which declares type parameters.