Make cannot deal with 'export *', they have to be escaped and fixed later on.

Should fix a problem with 'hadd -k ...' reported on the forum
(https://root.cern.ch/phpBB3/viewtopic.php?f=3&t=22843).

This is the recommended way of using the modules feature and should pave our way
of enabling -fmodules-local-submodules-visibility mode.

Use the standard #include <typeinfo> and #include <iosfwd> instead.

Our two build systems can generate almost entirely a modulemap file laying out
one module per library. Due to some non-modular implementation in ROOT's core we
still need to treat some header files specially.

This patch appends modular header files to the modulemap while skipping the
predefined ones. Configure-make relates all headers that are installed in
$ROOTSYS/include to their library whereas relates only headers which are part of
library's dictionary.

JSON content automatically zipped - makes produced file approx 3 times
smaller. By default, JSON code will not include any additional spaces.

Before object reference was done with the string like "$ref12".
This approach is error-prone, while any normal string with
similar content will confuse JSROOT.parse function. Now
other syntax is used: {"$ref":12}. Such output can never be
produced with normal C++ classes, therefore is absolutely safe.

Starting from JSROOT version 4.8, both formats are supported.
Means old JSON files, produced with older ROOT versions still
can be used with actual JSROOT code.

Normally each JSON object accounted in object map,
which is required when dereferencing objects.
This does not works with pair JSON objects,
which are created after all contained objects are stored.
Therefore pair marked separately and does not accounted in reference
map.

https://sft.its.cern.ch/jira/projects/ROOT/issues/ROOT-8495

ROOT were crashing when try to open TFile in TBrowser, which contains
objects, derived from TObject, but not as first parent.

For all TObject-based classes pointer was inadvertently casted to TObject and return in
this form. But if TObject is not a first parent of the resquested class, the return value was wrong.

This reverts commit bcec6aee.

This was the 'right' thing to do for Emulated class (due to a deficiency in TStreamerInfo::ComputeSize)
but wrong from loaded classes (where TClass::Size() is authoritative for use in vector).

Which this change we should be back to the emulated vector and a compiled vector being bitwise
identical.

Note the forced alginment was introduced in 9968d0f0
to more properly support emulated class (which is more comprehensively done by fixing TStreamerInfo::ComputeSize)

This avoid user of this size (like the emulation of std::vector) to have to align it
(and having to filter this alignment on just the emulated case)

Not all usecases are supported, clearly identify them in return value

1. When store members like
      TString* fStr[3][4]; //[fCnt]
   Array structure produce twice.
   And TArrayIndexCreator should correctly handle both cases
2. Straight-forward handling of multi-dim array
   when store object member. Special handling of char arrays
   as normal strings.

In JSON let store char* members as noraml string

This fixes ROOT-8478.

This avoid spurrious warning messages

When the TKey 'just' fits in whats left on the file to the next even boundary of billions of bytes, the end offset
of the block is not reset in TFree::GetBestFree, so we need to reset it in TKey::Create.

When the storing of the list of free block is large enough to make the file go from under 2GB to over 2GB, the
prediction of the buffer size need is wrong and thus we need to redo the TKey preparation (rather than blinding
doing an out-of-bound write [and of course missing the last few bytes when reading back]).

This was seen in the wild by CMS.