COM server refactor and improvements

[Charles Milette (sylveon)]

I originally only wanted to do the CLSID parameter change, but ended up spotting a lot of potential improvements:

• Moved the class factory somewhere public because it can be useful for more things than just the COM server. Also made it so that the class factory only uses winrt::no_module_lock for usage in OOP servers like register_com_server because an in-proc class factory does need to increment the module lock.
• Allow callers to alter the extra parameters of CoRegisterClassObject
• Added reasons to the nodiscards
• Made use of REGCLS_SUSPENDED in the overload that registers multiple instances
• Use CoAddRefServerProcess and CoReleaseServerProcess in the lock we use - and also turn it purpose specific. This now means that as soon as the ref count hits 0, further activations are suspended to avoid potentially racy conditions
• Now the COM server functionality lives in cppwinrt_authoring.h
• Disabled weak references to the class factory, to mirror WRL.

I wanted to look into adding aggregation support to the factory, but backed off for now because cppwinrt's composition support machinery is almost entirely within the winrt::impl namespace and assumes IInspectable.

The end consumer API is almost identical. Most tests where modified very lightly if at all.

Supplants #533

[Duncan Horn (dunhor)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Charles Milette (sylveon)]

I've pushed formatting fixes, however I am unsure what the errors on the clang build are about - they complain about illegal instructions but I don't appear to be doing anything that could trigger this.

[Duncan Horn (dunhor)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Duncan Horn (dunhor)]

I am unsure what the errors on the clang build are about - they complain about illegal instructions but I don't appear to be doing anything that could trigger this.

Not sure about the illegal instruction part. I wonder if it hit an int 3 or something like that, but idk if that'll give the same error. Given the test it's failing in uses coroutines and I know there have been issues with Clang and coroutines on Windows in the past, I'm curious if that's related. If so, it's kind of disappointing those issues haven't been ironed out yet.

[Duncan Horn (dunhor)]

roxk as FYI for the changes in file names/types

[Duncan Horn (dunhor)]

I wonder if it hit an int 3 or something like that

If it is indeed an issue with coroutine support in Clang, it could also be a bad jump pointer, etc.

[Charles Milette (sylveon)]

It's somehow hitting a compiler-generated ud2. When trying to call the AsyncActionCompletedHandler, i.e. after the coroutine is done running.

[Charles Milette (sylveon)]

Swapping the (...) in our completed handler for the appropriate parameters fixes it. lol.

[Charles Milette (sylveon)]

Should be fixed now.

[Duncan Horn (dunhor)]

/azp run

[Duncan Horn (dunhor)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).