[IMPL] Support IDxbcConverter from dxilconv.dll

[ds5678]

This implements support for IDxbcConverter from dxilconv.dll in C:\Windows\System32 using the header from DirectXShaderCompiler.

• I created a new class DxilConv so that DxcCreateInstance and DxcCreateInstance2 wouldn't conflict with the ones in DirectX for dxcompiler.dll. Should I have renamed them to DxilConvCreateInstance / DxilConvCreateInstance2 and put them in the DirectX class?
• Generated with ClangSharpPInvokeGenerator 20.1.8.2

Resolves #416

[tannergooding]

This file is notably in the "wrong" location, it should be somewhere under generation/include. It also, at minimum, requires updating the THIRD-PARTY-NOTICES.txt in the solution root and would be beneficial to know where it comes from.

That being said... typically the bindings in TerraFX.Interop.Windows are exclusive to what ships with Windows, the Windows SDK, or the DirectX Agility SDK. This header looks to be part of none of those and so is likely a "pit of failure" for users as it won't be usable "out of the box". The fact that it also creates a separate class to avoid conflicting with in-box APIs is problematic as well, because it creates a deviation from what users expect and where they're looking for APIs to be exposed.

This seems like something that should probably be its own repo/project, because its explicitly disconnected from what the DirectX SDK ships

[ds5678]

This file is notably in the "wrong" location, it should be somewhere under generation/include. It also, at minimum, requires updating the THIRD-PARTY-NOTICES.txt in the solution root and would be beneficial to know where it comes from.

My apologies for these things. I can fix them.

That being said... typically the bindings in TerraFX.Interop.Windows are exclusive to what ships with Windows, the Windows SDK, or the DirectX Agility SDK. This header looks to be part of none of those and so is likely a "pit of failure" for users as it won't be usable "out of the box".

It should be usable "out of the box" since dxilconv.dll is in C:\Windows\System32.

The fact that it also creates a separate class to avoid conflicting with in-box APIs is problematic as well, because it creates a deviation from what users expect and where they're looking for APIs to be exposed.

The DxilConv class indeed has a discovery issue. That's why I asked about renaming.

This seems like something that should probably be its own repo/project, because its explicitly disconnected from what the DirectX SDK ships

So should I close my issue and pull request, or make changes to this pull request?