Changes

[InstrProfiling] Use nobits as __llvm_prf_cnts section type in ELF

This can reduce the binary size because counters will no longer occupy
space in the binary, instead they will be allocated by dynamic linker.

Differential Revision: https://reviews.llvm.org/D97110

[libcxx] Make path::format a non-class enum

The spec doesn't declare it as an enum class, and being declared
as an enum class breaks referring to the values as e.g.
path::auto_format.

Differential Revision: https://reviews.llvm.org/D97084

[libcxx] [test] Call create_directory_symlink when linking directories

This makes the symlinks work properly on windows.

A similar round of cleanup was done in
c41bda7f5fc26e4602a029646991d6a5c59cb365, but these tests were
added after that.

Differential Revision: https://reviews.llvm.org/D97089

[NFC] Refactor PreferMemberInitializerCheck

[mlir] Register the print-op-graph pass using ODS

Move over to ODS & use pass options.

Update test error string post pass registration change

[lldb] Refine ThreadPlan::ShouldAutoContinue

Adjust `ShouldAutoContinue` to be available to any thread plan previous to the plan that
explains a stop, not limited to the parent to the plan that explains the stop.

Before this change, `Thread::ShouldStop` did the following:

1. find the plan that explains the stop
2. if it's not a master plan, continue processing previous (aka parent) plans
3. first, call `ShouldAutoContinue` on the immediate parent of the explaining plan
4. then loop over previous plans, calling `ShouldStop` and `MischiefManaged`

Of note, the iteration in step 4 does not call `ShouldAutoContinue`, so again only the
plan just prior to the explaining plan is given the opportunity to override whether to
continue or stop.

This commit changes the loop call `ShouldAutoContinue`, giving each plan the opportunity
to override `ShouldStop` of previous plans.

Why? This allows a plan to do the following:

1. mark itself done and be popped off the stack
2. allow parent plans to finish their work, and to also be popped off the stack
3. and finally, have the thread continue, not stop

This is useful for stepping into async functions. A plan will would step far enough
enough to set a breakpoint on the async target, and then use `ShouldAutoContinue` to
unwind the necessary stepping, and then have the calling thread continue.

Differential Revision: https://reviews.llvm.org/D97076