proxy-deprecation and server-directed EasyAuth

[As described here](https://github.com/Azure/Azure-Functions/issues/2047#issuecomment-1221419316), dropping support for proxies would eliminate another very useful scenario - protecting api-key-based APIs with [server-directed login flow](https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization#authentication-flow).

Even in Azure many APIs still do not support AAD-based auth and can only be protected with a nonce (api-key). Not to mention all other APIs one can possibly find on the Internet. To keep such an API protected while talking to it from a browser-based app would normally require implementing a backend, that authenticates and then proxies all the requests. This is where Azure Function proxies come really handy, because with them we can just append an api-key to every API call on-the-fly _without exposing that api-key to the public_ and without the need for custom backend logic.

On the other hand, server-directed (cookie-based) login flow is the easiest authentication scheme possible, because it doesn't require any auth-related logic on the client side. No extra code is needed, it can be just configured. And it is the [built-in feature of Static Web Apps](https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-authorization?tabs=invitations).

Combined with Function Proxies it gives an elegant solution - user gets authenticated upon their first request for HTML statics, then all API calls get the same auth cookie, they are being served by the proxy, which 'converts' that cookie into an api-key and sends them down to the API.

For this to work, the proxy needs to be hosted _under the same DNS name with HTML statics_ (cause that's how cookie-based auth works). That's why APIM can never be a replacement in this case.

Therefore I highly suggest preserving Azure Functions Proxies as a feature.