Remove mention of rotor from comments (#20297)

* Remove old reference to Rotor in documentation.

All remaining references relate to rotor's role in CoreCLR history.

* Remove rotor comment from enummem.cpp.

I can find no evidence that the presence of g_pStressLog is conditional
on FEATURE_PAL being defined.

* Remove old todo, DbgDllMain looks for thread detach.

* Update nativepipeline.h comment refernce to rotor.

All unix-like systems except android have FEATURE_DBGIPC_TRANSPORT_DI
defined, hence "most unix-like platforms".

* Update some comments to not refer to Rotor.

* Remove some more references to Rotor from comments.

* Remove old comment.

Though maybe this macro should be removed and everywhere use the & operator.
It appears there are only two places that use this macro.

1 files changed, 1 insertions, 1 deletions

diff --git a/Documentation/botr/exceptions.md b/Documentation/botr/exceptions.md
index 8e4b77a051..5e8a62cc9a 100644
--- a/Documentation/botr/exceptions.md
+++ b/Documentation/botr/exceptions.md
@@ -13,7 +13,7 @@ Exceptions matter almost everywhere. They matter the most in functions that thro
 Why are CLR internal exceptions different?
 ==========================================
 
-The CLR's internal exceptions are much like C++ exceptions, but not exactly. Rotor can be built for Mac OSX, for BSD, and for Windows. The OS and compiler differences dictate that we can't just use standard C++ try/catch. In addition, the CLR internal exceptions provide features similar to the managed "finally" and "fault".
+The CLR's internal exceptions are much like C++ exceptions, but not exactly. CoreCLR can be built for Mac OSX, for Linux, for BSD, and for Windows. The OS and compiler differences dictate that we can't just use standard C++ try/catch. In addition, the CLR internal exceptions provide features similar to the managed "finally" and "fault".
 
 With the help of some macros, it is possible to write exception handling code that is almost as easy to write and to read as standard C++.