[Request] Add extension to register all functions as services in DI container

# Proposal

Introduce a new `AddFunctionsAsServices` extension method on `IFunctionsWorkerApplicationBuilder` that automatically registers every function class detected by the functions framework in the dependency injection container.

This allows all function classes to participate in the container's self-checking logic during startup of the project, preventing runtime errors much later when actually executing specific functions if dependencies cannot be resolved.

# Background

AspNetCore MVC provides a [`AddControllersAsServices()` extension](https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.mvccoremvccorebuilderextensions.addcontrollersasservices?view=aspnetcore-7.0) that registers all controllers in the container automatically.

This not only enables things such as being able to decorate controller classes via the container, but more importantly it allows controller classes to participate in the Microsoft DI container self-checking mechanism, which iterates through all services registered in the container and checks whether or not their dependencies can be resolved. This mechanism is enabled by default while in debug mode and allows developers to catch DI-related errors much earlier in the pipeline: the validation error is raised during container construction, instead of only during a specific call to the affected controller action.

My proposal is that a similar extension be created for functions/durable functions, which would allow consumers to easily add all functions as services. A potential name for such extension could be `AddFunctionsAsServices()`, for consistency.

While consumers _can_ register functions manually themselves and still have them participate in the container self-check process, this approach is error-prone, creates coupling with the azure functions library, and potentially duplicates logic: users would be tasked with creating their own logic to "detect" all function classes, which is something that the functions framework _already does_ to perform its main job. The alternative is to manually register each individual function as separate calls, which not only doesn't scale well, but is fairly noisy, leads to situations where some functions are forgotten to be registered (which could then potentially lead to runtime issues being detected only after deployment), and also forces developers to remember to add a registration whenever they create a new function.

If the team is resistant to adding such helper extension, the framework should at least expose discovered functions in some sort of callback so that consumers could then register those types themselves without having to replicate the function detection logic.

This is a spin-off of:
- https://github.com/microsoft/durabletask-dotnet/issues/88

And a replication of:
- https://github.com/microsoft/durabletask-dotnet/issues/107

Start with IFunctionsWorkerApplicationBuilder and trace the functions framework's existing function-discovery path. Determine how discovered function and durable function types could be exposed to dependency injection without duplicating detection logic. Done means an AddFunctionsAsServices-style API registers every detected function so container validation catches unresolved dependencies during startup; the issue names no files or tests.

Written by the indexing model from the issue text.