This appears to be messy:  The /org.openoffice.Office.Views/WindowType
configuration group template has both a nilable bool "Visible" property and a
UserData/Data string property that encodes various things like geometry---but
also visibility---in a string.

Now, likely due to the problem that has meanwhile been fixed through
f3f79cc9 "Resolves fdo#46074: Fix
Partial::contains for paths that go past a leaf node," some
registrymodification.xcu files in the wild contain such WindowType entries in
"default" state, without a UserData/Data string and with a nil "Visible"
property.

The way SfxChildWindow::InitializeChildWinFactory_Impl and
SvtViewOptions::IsVisible are implemented, they will always lead to an invisible
window for such broken registrymodification.xcu data (as IsVisible unhelpfully
returns false for a nil value, and InitializeChildWinFactory_Impl uses that
value when there is no UserData/Data string).

For the Math formula editor window (ID 30378) this means that it can disappear
from the UI completely, as there appears to be no UI trigger for the user to
show it in case it is hidden.

The fix is to introdue SvtViewOptions::HasVisible (which only returns true if
the property is not nil) and change InitializeChidlWinFactory_Impl to only use
the value of IsVisible() if HasVisible() returns true.  This makes the code even
more baroque, but this is a rather central, generic piece of code for all sorts
of windows, so I do not want to break any other uses by e.g. changing IsVisible
to return true for a nil property.

Change-Id: Iae40075a7116a8aabd2d25aa9334709522e23d8f