There was a TODO to replace a manually managed array of Glyphs
to use std::list

a GlyphItem is 36 bytes long. the colleciton of GlyphItems is
mostly used in a sequential access. random insert/delete are fairly rare.
using std::list would increase the size by at least 8 to 16 bytes per
element (depending on the size of void*) (25 to 50% overhead)
and would greatly degrade data locality for most iterations loops.
so std::vector seems more appropriate here.

It is alarming that the Notes unit test did not fail for any of these
errors

I can't express how dumb I feel after searching for hours for a bug in
the note handling and then it is just such a small copy/paste error

We don't use it in gbuild/platform/IOS_ARM_CCC.mk either. Need to be
consistent or we get linker warnings. Should we use it? Probably it
isn't that important for iOS?

Nah, these dummy classes would turn out quite complex anyway. Better
to just use ifdefs elsewhere, the number required is not that large.

This reverts commit 6d33801b.

Thus no need to bypass the code here in the DISABLE_DBCONNECTIVITY
case. That is intended to get rid of code related to communicating
with more complex database systems.

Whether anything that's done in postprocess is relevant for iOS
remains to be seen.

make the original check more general, to cover all chart types that
don't support statistics

* Make typedefs private to class ScTabViewObj
* rename field aSelectionListeners to aSelectionChgListeners

There are still some more issues but at least they are now correctly
located in the right position

All advanced attributes are not yet applied.

Maybe it depends on the day of the week or something like that...