chart2: add a SolarMutexGuard in ChartView::createInstance()

SvxUnoNameItemTable::SvxUnoNameItemTable() registers a listener at
SdrModel, surely that needs a lock of some kind.

Change-Id: I80d5a31be66e75f07e8abd26504bdcc93ffd22a3
sc: lock SolarMutex before calling ScDocument::RemoveUnoObject()

This can race against other threads calling AddUnoObject(), and
hopefully this should fix the assert from SfxBroadcaster::AddListener()
line 96 that has been observed in sc_unoapi.

Change-Id: Ia2dd38a499c51a77c54cffe9dde31e14053ae0e5
SvxShape destructor un-register at broadcaster with SolarMutex locked

Change-Id: Ie9bd6d0fc1b221e77c4d37a26c999aa34afbe0ee
sc: ensure global variables in tests are cleared before shutdown

If the destructors run from exit handlers, they could access already
deleted globals from VCL etc. and crash.

Change-Id: I265046e95998a4384e1ce0f1f205d03c078a40a9
scripting: another missing SolarMutex guard

Change-Id: I762dad4d94ab4f27912b4ddac5b6a77f7d685cb8
sd: SdUnoForbiddenCharsTable gets a SolarMutexGuard too

Change-Id: Ie742b7e38e60f6a77f6b7c3e56ac415d8cb836e1
SwXAutoTextEntry: de-register on SFX_EVENT_PREPARECLOSEDOC event

Evidently (sw_unoapi) it's possible that ~SwXAutoTextEntry() completes
but the thing is still registered at a SfxBroadcaster - probably because
the Notify() method may clear xDocSh without de-registering.

Change-Id: I81a7f4ab3a9f3d685181891d6a7f5a826b7d2bf0
SfxBroadcaster: add some SolarMutex asserts

It is extremely likely that calling SfxBroadcaster methods without
SolarMutex lock is a bug; in case somebody finds a counterexample, this
should be reverted.

Change-Id: I4706671cfa22a3cfaed9cd33d4a77b14a57bb661
vcl: use DBG_UTIL for additional members in SolarMutexTryAndBuyGuard

... for consistency, and to keep the ODR police away.

Change-Id: Id4bf23be1e57cc29dfed9331d75034a33c2910f8