RFR: 8375359: Improve GC serviceability init staging

[Aleksey Shipilev]

As per docs, `CollectedHeap::post_initialize` is for doing inits that should be done before general allocations are accepted. Currently, serviceability layer initialized there via the call to `CollectedHeap::initialize_serviceability`. This bug shows that after `CollectedHeap::post_initialize` returns, the rest of the serviceability layer had not been fully initialized yet. But GC code might assume general allocation path works at that point! So if that allocation path reports anything to the serviceability layer, it could encounter not yet fully initialized serviceability support and fail.

This readily manifests in improved Epsilon stress test. Improved test fails pretty consistently on my machines, and serves as a good regression test.

So the fix is to peel off serviceability initialization from post-init stage, and do it separately, before going (and finishing) `post_initialize`. Conveniently, we are nearly there, and "just" need to touch up a few things in `universe_post_init()`.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `gc/epsilon/TestInitAllocs.java`, 10x
 - [ ] Linux x86_64 server fastdebug, `hotspot_gc`

-------------

Commit messages:
 - Fix
 - Stress test

Changes: https://git.openjdk.org/jdk/pull/29254/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29254&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375359
  Stats: 94 lines in 6 files changed: 42 ins; 5 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/29254.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29254/head:pull/29254

PR: https://git.openjdk.org/jdk/pull/29254