Fix Resource_Manager::Debug and Storage_Schema::ICurrentData() data races

[gsdali]

Description

Fixes #1398.

Resource_Manager::Resource_Manager(const char*, bool) (Resource_Manager.cxx:109) writes a
file-scope static bool Debug on every construction with zero synchronization. Two
Resource_Manager instances constructed concurrently on different threads (e.g. two independent
TDocStd_Application instances each lazily building their own via Resources()/DefineFormat())
race on this write. Fixed by making Debug a std::atomic<bool> — it is a plain process-wide
debug-logging flag, not meant to express per-instance intent, so an atomic is sufficient here.

Storage_Schema::ICurrentData() (Storage_Schema.cxx:802) is a function-local static
Handle(Storage_Data) mutated with no synchronization anywhere: Write() sets it for the
duration of one store, and any Storage_Schema construction — including a throwaway instance
built only to read header info, e.g. PCDM_ReadWriter_1::ReadDocumentVersion/
ReadReferenceCounter/ReadReferences, all reachable unconditionally from a plain
TDocStd_Application::Open() via CDF_Application::Retrieve — calls Clear() ->
ICurrentData().Nullify() in its constructor, which can null out a different, unrelated
Storage_Schema instance's in-flight Write() on another thread (or race a concurrent load's own
throwaway construction). Fixed by adding Storage_Schema::ICurrentDataMutex(), a
std::recursive_mutex (recursive because Write()'s own critical section re-enters
BindType()/AddPersistent()/PersistentToAdd() on the same thread via per-type
Storage_CallBack::Write() callbacks — a plain mutex would deadlock there) guarding every touch
point: the constructor's Clear(), Write()'s entire body (held for the whole call, since one
Write() is a single atomic "session" against this global, not just each individual access),
BindType(), TypeBinding(), AddPersistent(), PersistentToAdd(), HasTypeBinding(), and
ISetCurrentData().

Both races are invisible under the traditional single shared XCAFApp_Application /
TDocStd_Application usage pattern, because in that pattern Resources()'s own lazy-init mutex
happens to serialize Resource_Manager/Storage_Schema construction down to "runs once, ever, for
the whole process." They only become reachable once an application is constructed privately per
caller/thread (the pattern this project's own TDocStd_Application documentation recommends over
the deprecated XCAFApp_Application::GetApplication() singleton) and multiple independent
instances are built concurrently — see the linked issue for the full TSan writeup and a
standalone reproducer.

No public API signature changes.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

ThreadSanitizer (minimal-module build: FoundationClasses + ModelingData + ModelingAlgorithms +
DataExchange, RelWithDebInfo, -fsanitize=thread -g), 8 threads x 30 rounds, each round building
a brand-new private TDocStd_Application, defining formats, populating and saving a document,
closing it, then a separate brand-new private application opening + verifying + closing it — no
two threads ever share an application/schema instance.

• Before this fix: 13 TSan race warnings (2x Resource_Manager::Resource_Manager, 11x
  Storage_Schema::Storage_Schema's Clear() call), 0 functional failures.
• After this fix: 0 races across 4 repeated runs (8x30, 8x50, 10x60, 8x40), 0 functional failures.

Reproducer and full writeup:
https://github.com/SecondMouseAU/OCCTSwift/tree/main/Scripts/repro/374-resource-manager-storage-schema-race

Checklist:

• My code follows the code style of this project (clang-format --dry-run --Werror clean on
  every touched file)
• My change requires a change to the documentation
  • I have updated the documentation accordingly (no user-facing documentation covers this
    internal-only synchronization change)