winaccessibility: CMAccessible needs only one member for XAccessible

Merge aliases pUNOInterface and pRef; also pAchorUNOInterface is never
used.

Change-Id: I1b3841a9aca9d2438b25c66c7f67d09ce13b41f9
winaccessibility: CMAccessible needs only one XAccessibleContext

Merge aliases pRContextInterface (unused) and pRContext; this is
exacerbated by countless local variables pRContext that shadow the
member...

Change-Id: I6bc71911fb41a2ce2590d614020ecea36d6ab4f8
winaccessibility: make XAccessibleAction member Reference

Maybe it would be kept alive by AccObject::m_AccActionRef but why not
play it safe.

Change-Id: I03c2be04e97dcde8a177ef8dfd0d75595ab13a53
winaccessibility: don't need 2 global pointers for AccObjectWinManager

Sadly can't use rtl::Static because it needs a ctor parameter...

Change-Id: I98bbfbb4d2ef54f40a5f110527b260c0b5b01eed
winaccessibility: fix some error handling in CAccTable

Change-Id: I3c8bc6a476a6254a4ddc3a7cb0585544f3f78431
winaccessibility: let CoCreateInstance calls find the components

The COM services are not found because they are not registered in the
registry via regsvr32 (doing that is unnecessary since the components
are only instantiated by winaccessibility code and undesirable since
that would likely register the IAccessible2 types too, breaking A11y
tools) and the special manifest resource #97 that ActivateActContext()
tries to load does not exist in UAccCOM.dll; this would need to be a
XML manifest, the *.rgs and *.tlb that are already included as
individual resources won't work.

After reading ATL headers for hours it is immediately obvious that the
COM components can simply be registered by a call to
CComModule::RegisterClassObjects() from DllMain; this just requires
actually loading the UAccCOM library from somewhere so the DllMain runs.

Change-Id: Id58b754835cd2f1bcada37e5639a6b6042a42fd5