Interceptors - "experimental" designation and breaking changes

[RikkiGibson]

Main issue: #7009

• We want to reserve the ability to make breaking changes or to entirely remove the interceptors feature after shipping it .NET 8. Therefore we're using the experimental designation for it.

• Users have to set a property <Features>InterceptorsPreview</Features> in their project to use interceptors.

• ASP.NET Native AOT projects set the above property implicitly. We've given ASP.NET permission to depend on the feature in this way in the short term. This scenario is considered stable for end users.

• At the same time we've made it clear to ASP.NET that we may drop support for this feature, and it's expected that if we do that they will have to ship a servicing release to account for it.

• In practice shipping a "prototype"/"experiment" can go out of your hands. There's a risk of not having time to make the changes you'd like to make in the subsequent release(s). It's possible to end up marking the feature "stable" and shipping it with minimal changes because it's expedient.

• With that in mind we want to examine the possible scenarios where we might drop the interceptors feature.

  1. We decide to divest from the native AOT space. This is unlikely but possible. In this case, ASP.NET's solution is to move back to their "overload resolution based" generator which they've already implemented.
  2. We come up with another solution which addresses very similar use cases to those addressed by interceptors. In this case, ASP.NET's solution is to migrate to our new solution.

• We think the risk of the experimental approach is relatively low, because we think a relatively low amount of work is needed to change it in either of the above cases.

• ASP.NET's generators ship in a ref-pack. This means that making a change to them is a servicing event for the .NET runtime. The relevant teams know and understand this.

• Because generators run in VS, ref packs already need to be serviced when performance bugs are found, for example. Essentially, we're already in a position where ref packs may need to be serviced for reasons which are "incidental" to that particular target framework.

[333fred]

Discussed in LDM: https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-24.md#interceptors