Support tlbreference (for registration-free COM) in TlbReference Task

When using `` items, tlbimp is invoked for each one separately, and any `importlib` references to other typelibs are expected to resolve through the registry. This can fail if the typelibs are use importlib to reference one another, but are not entered in the registry, e.g. building on CI with artifacts retrieved by a package manager, or importing from a COM server DLL which also contain a WinSxS manifest and is intended for ues via [registration-free COM](https://docs.microsoft.com/en-us/dotnet/framework/interop/configure-net-framework-based-com-components-for-reg).

tlbimp.exe does support this use-case, via its [`/tlbreference` command-line switch](https://docs.microsoft.com/en-us/dotnet/framework/tools/tlbimp-exe-type-library-importer). But while TlbReference.GenerateWrapper does support `/reference` in both the tool paths https://github.com/dotnet/msbuild/blob/e70a3159d64f9ed6ec3b60253ef863fa883a99b1/src/Tasks/TlbReference.cs#L174
it does not seem to in the non-tool path, and neither supports the use of /tlbreference
https://github.com/dotnet/msbuild/blob/e70a3159d64f9ed6ec3b60253ef863fa883a99b1/src/Tasks/TlbReference.cs#L261

It would be nice if there was support for a `` property in within the `` item, or (maybe even better) some easy way, perhpas even just on-by-default, to simple make all typelibs mentioned by `` items available to mutually satisfy each other's importlib references, falling back to the registry only for a libid not found among the explicitly-named files.

For even more bonus points, it would be wonderful if this could (presumably optionally) generate the appropriate `` manifest from `` items that have an ``.

For the non-tool path, an easy way to achieve this would just be to LoadLibrary on each typelib mentioned by `` before beginning to translate any of them. From previous experience, the implementation of ITypeInfo::GetRefTypeInfo seems to be able to find things in already-loaded typelibraries even if they are not in the registry. For the external tool path, that could involve passing a number of `/tlbreference:path` options, some probably unnecessary.

This is not really an issue for `` items, since those are themselves looked-up via the registry, so it seems reasonable to expect that their dependencies would be registered as well.