Revisit .tlb generation with dscom

This is partly an issue and partly documenting the current behaviour.

Our current approach to making a .tlb file with dscom is to require it to be installed as global tool.

Then a project targeting .net6.0-windows can have this property set:
```
true
```
and everything works.

This does not build when targeting .NET Framework - we get an error
```
1> MSBUILD : ExcelDnaBuild error DNA731704007: Cannot start process because a file name has not been provided.
1> MSBUILD : ExcelDnaBuild error DNA731704007: System.InvalidOperationException: Cannot start process because a file name has not been provided.
1> MSBUILD : ExcelDnaBuild error DNA731704007: at System.Diagnostics.Process.Start()
1> MSBUILD : ExcelDnaBuild error DNA731704007: at ExcelDna.AddIn.Tasks.Utils.ProcessRunner.Run(String fileName, String arguments, String appName, IBuildLogger log)
1> MSBUILD : ExcelDnaBuild error DNA731704007: at ExcelDna.AddIn.Tasks.CreateExcelAddIn.TryCreateTlb()
1> MSBUILD : ExcelDnaBuild error DNA731704007: at ExcelDna.AddIn.Tasks.CreateExcelAddIn.Execute()
```

**Q: I think DsCom can work when targeting .NET Framework too. Is enabling this (by fixing the problem above) perhaps a good alternative to using the TlbExe where we need to locate the path etc.**

(We still want the TlbExp option, since it has some features that DsCom does not support.)

An alternative that does not require the global tool install is to use the DsCom package like this (without `ExcelAddInTlbCreate`)

```

```

I think this is good, and seems to work fine for both .NET Framework and .NET 6.

**Q: Is there a better way to deal with the required path in `DsComTlbExportAssemblyPaths` (which we need so that ExcelDna.Integration.dll will be found by DsCom)? I'm also not sure whether the net6.0-windows vs net452 is important in the path here.**