The new DI project is intended for usage with Microsoft.Extensions.DependencyInjection, and provides the AddMessageBus extension method.

This commit implements the event side of the bus (Observe/Notify) and ports all tests from the EventStream to ensure behavior compatiblity.

The existing code from CommandBus was ported pretty much entirely,

Removed restriction on Notify for externally produced events, since subscribers can still get it in either case, so this adds consistency.

This new implementation is more performant than the original CommandBus for public types, since it relies on dynamic dispatch which is faster, as meassured by the new benchmarks project. For the non-public types scenarios, it performs like the original command bus, which is great too and only incurs a downcast.

This finally brings all hosting scenarios to use the same implementation and finally removes the legacy ICommandBus and IEventStream.

This removes the need to register command handlers with more than just the handler interface they implement.

Document how to decorate the default message bus too.

This adds an incremental source generator to the DI package that
discovers services annotated with [Service(lifetime)] so that they
can be properly registered in the service collection with the
right lifetime as well as proper instantiation and registration of the
required interfaces for the bus to work properly.

Since the os matrix is configurable now and we use windows-latest, we'd otherwise never push a CI package

This will make it easier to keep the dependency up to date with dependabot

…manifest

Packaging projects don't consider the TF in the project
itself to be meaningful for declaring dependencies.
Not declaring the dependency as targeting any TF,
however, causes the transitive dependency to not be
restored at all. So we make it TF specific by setting the
TF to the project's TF.

Since we get it from the one made public via a
partial class in the sample project.

Now that the latest DI generator supports MEF attributes,
we shouldn't test in teh same proect types annotated with
MEF attributes with the actual MEF tests since we'd get
duplicate registrations in some cases.