#1014 Pipeline and Services Abstractions

[Mayron]

closes: #1014

I have created 2 new abstraction packages/projects: MediatR.Pipeline and MediatR.Services (feel free to rename them). I have left MediatR and MediatR.Contracts untouched and have included MediatR.Contracts as a NuGet package dependency on the new packages.

Eventually, MediatR can include these 2 new NuGet packages as dependencies and remove the duplicate interfaces from its source code.

I left out the interfaces used in MediatR inside the MediatR.Pipeline namespace because they're more coupled with pipeline-related concepts and I don't think these are being requested from the initial issues raised. If more work is required, let me know or feel free to update this PR.

---

The reason for these additions is to allow for more architectural flexibility when using MediatR (which also solves my initial issue). For more information, please refer to the linked issue.

TL;DR: I can have one project depend on the MediatR.Pipeline NuGet package to store implementations of handlers and behaviors without being allowed to use services to send nested requests, and I can have another project depending on the MediatR.Services NuGet package for sending requests without implementing handlers.

[jbogard]

See discussion, I'm not interested in splitting packages out any further unless there are demonstrated needs for multiple applications or published libraries (i.e., beyond a single application) to reference a subset of MediatR features AND having the said features in a single library is preventing some capability.