Create new class to handle external validation, and rename existing dll loading class.

[bob80905]

This PR creates a class that is responsible for loading and unloading dxil.dll, allowing for external validation.
Tests are added to test this class's functionality. Additionally, an interface is defined that joins the existing singular dll loading helper class, and the new class that tracks two dlls. The classes were renamed to be more abstract, as well as all existing uses of the original singular dll loader class.
Fixes #7422

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[tex3d]

I had a number of comments, but many of these issues would have been noticed when trying to create a unit test that used this new DxcDllExtValidationSupport class. I think we need a unit test.

[damyanp]

I have a few comments, and things I suspect we'll want to revisit in the future, but I don't think that necessarily should block this PR.

[damyanp]

See comments

[tex3d]

I know I already debated this at length, but I object to this new approach that doesn't derive from dxc::DxcDllSupport. I don't think it'll fit nicely with the current users of dxc::DxcDllSupport& that don't care which DLL you've passed down, as long as it supports creating the interfaces needed. This wrapper forces a decision by a function of whether to take this wrapper or a dxc::DxcDllSupport& when none of the functions that currently have dxc::DxcDllSupport& arguments need to know the difference.

The problem isn't visible yet because this is only the first step of creating the new class. You haven't actually used it yet. It will become apparent as you try to hook everything up.

For instance, FileRunTestResult::RunFromFileCommands takes dxc::DxcDllSupport&, and you'd need to change this type for this design, but the DLL it manages isn't necessarily DxCompiler.dll. For DxilConvTest it points to DxilConv.dll, and it makes no sense for that test to use this class. Issues cascade from here, as other paths will want to point to DxCompiler.dll instead. Now these aren't interchangeable, so you have to make the code that uses dxc::DxcDllSupport& more complex to account for different DLL possibilities that it shouldn't need to know about.

Perhaps this PR needs to include the changes to all the places that will need to accept this new object just to see the impact of this design decision.

[V-FEXrt]

nit: Can we just drop the 2 here and rely on overloading? The param list is different so I think the compiler would be happy

[bob80905]

I believe we should keep the 2, since the 2 is in reference to the 2nd creation function, which is stored as a member variable in dxcapi.use.h: m_createFn2.
This different name helps clarify that it depends on the different function represented by that other member variable.

[bogner]

The interface is a good idea, but there are a couple of things that still need some work here. Notably, Tex's concerns are about the usage of the DxcDllSupport APIs, and as is this doesn't really address those users.

I would expect the base class (which you currently call IDllSupport) to be the thing that's used in most APIs if they just need to generically have a dll that can be loaded. If some APIs require the new fallback-aware version, they might take that concretely instead. If some need to use a specific dll and fallback wouldn't make sense, they might take that one concretely. The current patch continues to use DxcDllSupport in all of the users, so it doesn't really give us a path for how one would use DxcDllExtValidationSupport instead.

A note on naming. IDllSupport probably isn't a great name. We don't really have a convention of prefixing "I" for interfaces, and it's generally better if this name tells us what the object is for. Just DllSupport or something like DllLoader might be better - though there's also a weak argument to reuse the DxcDllSupport name to simplify user's API updates. I would probably change the name of the current DxcDllSupport to something like SpecificDllLoader to indicate that it concretely loads one and only one dll. DxcDllExtValidationSupport is pretty specific to the particular case so that name is probably okay (though if we do change to the "Loader" noun then it should change as appropriate).

As for usage, there are a number of places that pass DxcDllSupport objects around today - how do they need to be updated based on the change you're doing here?

• Some users are trying to load dxcompiler, and could use the external validator version. These presumably want the base object
• Some users use these APIs to load some other specific Dll. Using the ext validation support version wouldn't make any sense here, so they probably want the Specific Dll object.