Gap between init and post-attach drmemtrace start causes problems

DR's process initialization when attaching via the app start/stop interface is performed with other app threads running natively. This is followed by a staggered attach to all the threads. For drmemtrace we use -align_endpoints which does not turn on tracing until every thread is attached to: i.e., the earlier-attached threads have now been running for a bit in non-tracing mode, in addition to the time they ran during init.

These two gaps cause multiple problems involving missing data between process initialization snapshots and tracing-monitored application activity, including between the timer walk and monitored timer syscalls, leading to failing to scale timers activated in the gap (for #7504). This also means that process init can have races with native app threads if they both operate on shared resources.

The brute-force solution is to attach to and suspend all threads first, and only then run process init and then let them all go. We've always shied away from this due to fears that it takes too long to attach if there are thousands of threads using signals. We also have a lot of initialization in some use cases, some of which does not care about the gap.

Today DR has a process init event and a post-attach event. Maybe we could change those to a "pre-init" event that clearly documents the races and gap and we use that for as much heavyweight init as we can when it doesn't mind the gap (British pun not intended) and a regular init event that promises that the app is suspended and there will be no gap.