Make features public to enable testing/customization scenarios

[twsouthwick]

This exposes the internal features we use to enable System.Web scenarios for two main reasons:

1. Some functionality (such as ITransferRequestFeature) is not implemented out of the box
2. Requests have been made to have access to this for mocking purposes

For now, these are marked as experimental using the new ExperimentalAttribute to give us flexibility to change them if we need to since we haven't had to use them outside of our codebase. They have been moved into the Microsoft.AspNetCore.SystemWebAdapters.Features namespace as part of this change.

Fixes #332

[twsouthwick]

@joperezr I'm making use of the ExperimentalAttribute here - is there support for this for downlevel, or should we just enable it for .NET 8+?

[joperezr]

@joperezr I'm making use of the ExperimentalAttribute here - is there support for this for downlevel, or should we just enable it for .NET 8+?

The attribute itself is .NET 8 only, but the feature is built-in to the compiler so the suggestion for downlevel is just to define an internal attribute that looks just like the .NEt 8 one, and the compiler won't care in which assembly it is defined

[twsouthwick]

@joperezr I'm making use of the ExperimentalAttribute here - is there support for this for downlevel, or should we just enable it for .NET 8+?

The attribute itself is .NET 8 only, but the feature is built-in to the compiler so the suggestion for downlevel is just to define an internal attribute that looks just like the .NEt 8 one, and the compiler won't care in which assembly it is defined

Cool. I added an internal one for downlevel then. Since people may be using it on .NET 6 as well, will they not see any compiler warnings? Does it make sense to add an obsolete to that as well (with the diagnostic id?)?