Simplify further Azure Service bus message handling

[stijnmoreels]

As described in #470 , the Messaging library is being made quite simpler by reducing dependencies and functionality. In a next phase, we could take up the naming and types being used, to an even simpler messaging system. This discussion item acts as parent for this exercise.

Simplify user-implemented Azure Service bus message handler interface

Currently, users of Arcus.Messaging should implement an interface located in a long namespace, with a lot of noise in both the interface name and its type. Since the message context is also being adapted (#547 , #539), it is a good opportiunity to further think about what this could represent.

This is the pseudo-code proposal of how the end-result could look like:

namespace Arcus.Messaging
{
    public interface IServiceBusMessageHandler<TMessage>
    {
        Task ProcessMessageAsync(
            TMessage message,
            ServiceBusMessageContext messageContext,
            MessagCorrelationInfo messageCorrelation,
            CancellationToken cancellationToken);
    }
}

Note the following:

• The namespace is simplified, making adoptation of the message handling easier;
• The Azure... prefix is both removed in the interface type as in the message context, removing unnecessary noise.

There are several migration steps we can take to get to this end-result, all of which make sure that we support backwards compatibility.

[fgheysels]

I think it would indeed be good to make the types that are used the most, more discoverable. It would further simplify the usage of Arcus.
Some open remarks / thoughts though:

• Should we use 'Arcus.Messaging' as the namespace that contains the IServiceBusMessageHandler or should it be Arcus.Messaging.Azure?
• What about the multitude on Messaging projects that we have ? We have for instance Arcus.Messaging.Abstractions.ServiceBus and Arcus.Messaging.Pumps.ServiceBus. Can't we just merge them into one Arcus.Messaging.ServiceBus csproj (and nuget package) ?

[stijnmoreels]

Should we use 'Arcus.Messaging' as the namespace that contains the IServiceBusMessageHandler or should it be Arcus.Messaging.Azure?

Could be, thinking mostly about minimizing the amount of namespaces that people need to add. If we place both the interface, message context, and correlation info in the same one, they only need to have a single using statement.

What about the multitude on Messaging projects that we have ? We have for instance Arcus.Messaging.Abstractions.ServiceBus and Arcus.Messaging.Pumps.ServiceBus. Can't we just merge them into one Arcus.Messaging.ServiceBus csproj (and nuget package) ?

Yes, definitely something we can look into. Will make it even more easier and maybe make the exposed functionality also minimized. Think it was also extracted in .Abstractions for it to be used in other places - like Azure Functions.