.Net: Bump ONNX to 0.5.2

[RogerBarreto]

Motivation and Context

• The Latest 0.5.0 package also requires the caller to handle the resources with the OgaHandler instance, when a service is instantiated this resource needs to be also present and exposed together with the service. Otherwise a message will be sent to the console and the application will crash before finishing.

• Resolves .Net: Bug: Application crashes when using the ONNX connector and OnnxRuntimeGenAI v0.5.0 package #9628

[f2bo]

Doesn't this change mean that the model is reloaded into memory every time that you run an inference? This might take several seconds each time.

On the other hand, isn't having multiple OgaHandles, one for each service instance, a problem? It's not guaranteed that you will only have a singleton instance and disposing of one of the ONNX services will shut down the ONNX runtime for the process, so that all other services become invalid.
On the other hand, isn't creating multiple OgaHandles, one for each invocation of the service, a problem? The handle is disposed after the first invocation, which will shut down the ONNX runtime for the process and as a result, any subsequent invocations should fail.

[RogerBarreto]

@f2bo This won't be merged as is, I will add some extra Unit Testing to ensure it doesn't affect the status-quo, for the moment recommend using the ONNX Connector with previous version of GenAI.

[f2bo]

Rather than relying on users to ensure that an OgaHandle is created and disposed, I wonder if you have any objections to the following change:

public sealed class OnnxRuntimeGenAIChatCompletionService : IChatCompletionService, IDisposable
{
    ...
    private readonly static OgaHandle s_ogaHandle = new();

    static OnnxRuntimeGenAIChatCompletionService()
        => AppDomain.CurrentDomain.ProcessExit += (_, _) => s_ogaHandle.Dispose();
  ...
}

[RogerBarret0]

@f2bo Yes, I personally object this approach as this injects static resources and behavior on customers environment/application domain without their knowledge to handle a non-conventional resource monitoring.

And some other considerations regarding the potential pitfalls of using ProcessExit on different platforms.

1. Execution Time Limit: ProcessExit handlers have limited time and may not finish long-running tasks.
2. Unreliable State: The app may already be in an inconsistent state when the event fires.
3. Unhandled Exceptions: Errors in handlers are hard to debug and can terminate the app abruptly.
4. Cross-Platform Inconsistencies: Shutdown behavior varies across platforms and may bypass ProcessExit.