Summary:
# Changelog: [Internal]

Added OS-agnostic module that will implement 2 basic capabilities:
- Getting current process id
- Getting current thread id

This information will later be used in `PerformanceTracer`, which is trace-engine for recording profiles that can be inspected in Chrome DevTools.

Differential Revision: D69316093

Summary:
# Changelog: [Internal]

Use newly added module to get real OS-level process and thread ids.

We will keep process id on an instance, because I don't think it could change over time? For thread id, we will get it at the time of event registration.

Differential Revision: D69316094

Summary:
Pull Request resolved: facebook#49083

# Changelog: [Internal]

> NOTE: Some CI jobs are expected to fail, because changes in Hermes D67353585 should be landed first, and then grafted to Static Hermes.

Added 2 new public methods to `PerformanceTracer` instance for registering metadata Trace Events for processes and threads.

Differential Revision: D68439733

Reviewed By: huntie

Summary:
# Changelog: [Internal]

When we start tracing, we will record metadata events for current process and thread.

We will base it off the assumption that the thread where we handle `Tracing.start` event is the main one.

Differential Revision: D69465926

Summary:
Pull Request resolved: facebook#48836

# Changelog: [Internal]

When `Tracing.start` CDP method is received, here is what happens next:
- `TracingAgent`, which intercepts the event will propagate this status to `Instance` by calling `startTracing()` on `InstanceAgent`.
- `InstanceAgent` will propagate it to `Runtime` entities. The only difference, there is no concept of tracing for Runtime, it will only have an API for starting sampling profiler.

When `Tracing.end` CDP method is received, it is propagated in the same order.

There is also `collect*()` methods for collecting profiles.

This has multiple benefits:
- We can control when `Runtime` or `Instance` are recreated and can ask them to start recording trace profiles right away. This may be required when we would add support for Reload and Profile from Performance panel.
- We might leverage this setup in the future, once we add instrumentation for Network panel. `InstanceAgent` will get notified when tracing started and will correspondingly notify other part of the infrastructure that will be responsible for recording network calls.
- We remain being fully agnostic to the actual `Runtime`, see corresponding `RuntimeTargetDelegate` for `V8`. We don't have the capacity for implementing and maintaining sampling profiler capabilities for it, but this approach unblocks it from technical perspective, if someone would want to invest into this.

`InstanceProfile` is a superset of `RuntimeSamplingProfile`. In the future, `InstanceProfile` may also include things like `NetworkProfile`, or similar stuff.

The definition for `RuntimeSamplingProfile` will be added in D68414421 and relies on the availability of new API for sampling profiler in Hermes.

Differential Revision: D68327630

Reviewed By: huntie

Summary:
# Changelog: [Internal]

We need an ability to report the JavaScript thread id to Performance Tracer.

My thinking is that InstanceAgent should be responsible for it, since React Native Instance coordinates the threads: Main vs JavaScript.

When tracing will start `InstanceTarget` will register itself for tracing and will execute the code on JavaScript thread to record it.

Differential Revision: D69530983