Remove OpenGLProvider and add project reference instead

[Morilli]

I think this makes more logical sense and makes it easier to add new classes and functions in the future, and will also help if we ever want to use hardware contexts for other renderers (vulkan, direct3d) and would have to do the same frontend graphics integration there. See also #4758 for an example where this helps implementation.

Check if completed:

• I have run any relevant test suites
• I, the commit author, have read the licensing terms for contributors (last updated 2024-06-22) and am compliant

[YoshiRulz]

Was this to avoid a name collision or something?

[Morilli]

Yeah, BizHawk.Common.CollectionExtensions and System.Collections.Generic.CollectionExtensions.

[YoshiRulz]

Cause is an explicit (non-Source Generator) backport... BY MS https://github.com/dotnet/runtime/blob/c369fd627a26b606f36e6b3cbef6f25f3c00bbac/src/libraries/Microsoft.Extensions.DependencyModel/ref/Microsoft.Extensions.DependencyModel.cs#L221-L223 -_-
which we depend on via Silk.NET, hence no collisions before adding the dep on Bizware.Graphics.
edit: dotnet/runtime#129881

[Morilli]

Considering upstream seems unwilling to fix this, do you think this workaround is fine as is or can you think of a better solution?

[YoshiRulz]

There's a mechanism for dealing with libraries that misbehave like this: assembly/reference aliases. See new commit below.

Also FFS upstream locked the issue so I can't edit in this workaround -_- if any future humans made it here, it's simply <PackageReference Include="Microsoft.Extensions.DependencyModel" Alias="ms_ext_depmodel" />

[Morilli]

Soo how does this help when we still get a conflict between BizHawk.Common.CollectionExtensions and System.Collections.Generic.CollectionExtensions now?

[YoshiRulz]

It should only conflict when the type is referenced by name i.e. for a non-extension member, which is rare. We should eventually rename the type though.