Allow Wildcard based message Type mappings

### Describe the feature

It would be useful to have more complex type mappings, based on regex, wildcards, or prefix concepts, to allow implementation of generic handlers that can ignore unsupported message types.

### Use Case

I'm using the library to process GitHub events that are being placed on a SQS queue. The events are wrapped in a CloudEvent envelope as described in https://github.com/cloudevents/spec/blob/main/cloudevents/adapters/github.md

When configuring GitHub apps, the selection of event types emitted is a bit wider than what my application needs. For instance, I case about `release.published` events, but the GitHub App Webhook mechanism is setup to seen all types of Release events. I care to register in my .Net service a `IMessageHandler` for a `ReleasePublishedEvent`, and can do so with :

```
x.AddMessageHandler("com.github.release.published");
```
If an event of other types enters the queue (such as a `release.unpublished`), because there is no defined type or mapping for it, it becomes a poison message on the queue and blocks the processing.

Having a Fallback Handler, or a mechanism to suggest that any `com.github.release.*` type (or event wider `com.github.*` or even a catch_all `*`) can be processed by some generic Message handler or Ignore Handler would be great.

### Proposed Solution

A few options i can suggest:

* Add a configuration mechanism to allow Ignoring Unmapped types . Similar to https://github.com/aws/aws-dotnet-messaging/issues/165 it could be along the lines of :
```
x.IngoreMessagesForUnmappedTypes();
```
Which in needed could end up producing a `MessageProcessStatus.Success();` . It would skip without "polluting" a DLQ.

* Support a wildcard or prefix based mapping:
```
x.AddMessageHandler(WildCardMapping.From("com.github.repository_dispatch.*"));
x.AddMessageHandler(PrefixMapping.From("com.github."));
```
This could be a mechanism to use a message handler on a more generic event type (Envelope with a `dynamic` data payload, for instance). Exact type mappings would have precedence, over this, though (or registration order)?

* Extension mechanisms on the EnvelopeSerializer / MessageSerializer to override the decision mechanisms, and allow implementers to inject new decision elements. BTW, is this already supported in any capacity?

### Other Information

_No response_

### Acknowledgements

- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### AWS.Messaging (or related) package versions

AWS.Messaging 1.0.1

### Targeted .NET Platform

.NET 8 +

### Operating System and version

Linux Containers

Start by tracing the AddMessageHandler configuration and how EnvelopeSerializer, MessageSerializer, and MessageProcessStatus handle unmapped message types. Compare the proposed ignore, wildcard or prefix mappings and fallback-handler options, then define tests for exact-match precedence and the chosen behavior for unsupported events.

Written by the indexing model from the issue text.