[windows services] Fix shutdown races

- Do not keep the initial service thread alive for the lifetime of the
  service. There is no requirement to do so, and ordinary COM services
  do not need this thread for any reason. Delegates that provide their
  own Run() method may choose to keep the thread alive if they wish.
- Call PreRun/PostRun on the process's main thread rather than on the
  initial service thread since they should be called on the same thread
  and the initial service thread isn't suitable due to the fact that it
  is no longer kept running.
- Since there is no longer a concept of the "service main thread" there
  is no "current" sequence/thread task runner available when the
  delegate's various methods are invoked. As such, the updater service
  now runs its own SingleThreadTaskExecutor in its Run method.
- Set the module release callback before registering com class objects,
  as it's possible that another thread could rapidly process a request
  and trigger module release.
- Use a lock around all state associated with shutdown to be sure that
  there are no data races in those scenarios.
- Avoid thread hops before telling the SCM that the service has stopped.
  Any delay appears to increase errors by high-frequency callers.
- Move registration of an empty FeatureList into ServiceProgramMain so
  that it's alongside other generic process initialization.
- Move the tracing service's IPC thread and mojo setup into its
  delegate's PreRun/PostRun since that is now a logical/suitable place
  to do so.

Fixed: 375097840
Change-Id: Icc71ed3cd6a825097e8ce0c445df536b72f877dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6026072
Commit-Queue: Will Harris <wfh@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Auto-Submit: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1384972}