Add a method for user programs to be notified when a worker thread is started or stopped

[ThadHouse]

For some languages, they need a way to be notified of worker threads that will call back into user code (specifically Java). They need to be notified both on starting and stopping. This PR adds a new callback that can be set to allow users to know.

Testing still needs to be added, but wanted to double check the API.

[nibanks]

I'm still not really a big fan of exposing this. If at all possible, I prefer it scope this to the abstraction layer instead. Can we put this on the back burner and discuss more next week?

[nibanks]

For one, if multiple components in the same process are trying to use the same msquic library, with this model, they can step on each others' toes. I really prefer a language specific version of msquic that wouldn't result in that type of issue (because they wouldn't be shared).

[ThadHouse]

Yeah we can figure it out next week.

[ThadHouse]

One thing I realized while going through the code is that workers are created in registration. I thought they were created in the library. Because of this, we could actually add them as another field to QUIC_REGISTRATION_CONFIG, and then it would be scoped to the registration, although that is a binary breaking change. Realize we should have passed in a size for that config.

Also, building a separate copy of the library doesn't actually solve the same process sharing issues, you'd run into the same things either way, unless we passed in through the registration.

[ThadHouse]

Thats a lot better, and much more scoped in too. It is more of a breaking API change then the previous idea however. I'll write up a small demo app to show how this would actually work with the thread locals. IIRC, .NET can also use functionality like this.

[nibanks]

You can make this non-breaking by putting it behind a "custom" execution profile flag. Though, still I don't believe it should be architected this way.

[wkgcass]

Based on this approach, in my opinion, an improvement could be made:

The new field in QUIC_REGISTRATION_CONFIG could be changed into a struct and allow it to store some user data.
Something like:

struct QUIC_WORKER_CONFIG {
    void WorkerStateHandler(QUIC_WORKER_EVENT_TYPE EventType, void* UserData);
    void* UserData; // will be passed into the 'WorkerStateHandler' function
} QUIC_WORKER_CONFIG;

typedef struct QUIC_REGISTRATION_CONFIG {
    const char* AppName;
    QUIC_EXECUTION_PROFILE ExecutionProfile;

    QUIC_WORKER_CONFIG WorkerConfig;
} QUIC_REGISTRATION_CONFIG;

In this way, users will be able to pass in JavaVM* into UserData, and directly use the UserData pointer in the callback function instead of using a global variable.
This also allows users to use different variables for different registrations.

[nibanks]

Another problem with the current approach is that it is only for the app's specific registration threads. It isn't applied for the shared listener threads.

[ThadHouse]

Replaced by #1142