Modernizes some examples in the autoloading guide

Those examples were obsolete, because nowadays using a reloadable
constant in initializers is not just a bad idea, it is indeed not
possible.

The patch updates the examples accordingly.

Author: fxn

guides/source/autoloading_and_reloading_constants.md

@@ -244,12 +244,10 @@ Let's imagine `ApiGateway` is a reloadable class and you need to configure its e
 
 ```ruby
 # config/initializers/api_gateway_setup.rb
-ApiGateway.endpoint = "https://example.com" # DO NOT DO THIS
+ApiGateway.endpoint = "https://example.com" # NameError
 ```
 
-a reloaded `ApiGateway` would have a `nil` endpoint, because the code above does not run again.
-
-You can still set things up during boot, but you need to wrap them in a `to_prepare` block, which runs on boot, and after each reload:
+Initializers cannot refer to reloadable constants, you need to wrap that in a `to_prepare` block, which runs on boot, and after each reload:
 
 ```ruby
 # config/initializers/api_gateway_setup.rb
@@ -277,15 +275,15 @@ end
 
 ### Use Case 2: During Boot, Load Code that Remains Cached
 
-Some configurations take a class or module object, and they store it in a place that is not reloaded.
+Some configurations take a class or module object, and they store it in a place that is not reloaded. It is important that these are not reloadable, because edits would not be reflected in those cached stale objects.
 
 One example is middleware:
 
 ```ruby
 config.middleware.use MyApp::Middleware::Foo
 ```
 
-When you reload, the middleware stack is not affected, so, whatever object was stored in `MyApp::Middleware::Foo` at boot time remains there stale.
+When you reload, the middleware stack is not affected, so it would be confusing that `MyApp::Middleware::Foo` is reloadable. Changes in its implementation would have no effect.
 
 Another example is Active Job serializers:
 
@@ -294,7 +292,7 @@ Another example is Active Job serializers:
 Rails.application.config.active_job.custom_serializers << MoneySerializer
 ```
 
-Whatever `MoneySerializer` evaluates to during initialization gets pushed to the custom serializers. If that was reloadable, the initial object would be still within Active Job, not reflecting your changes.
+Whatever `MoneySerializer` evaluates to during initialization gets pushed to the custom serializers, and that object stays there on reloads.
 
 Yet another example are railties or engines decorating framework classes by including modules. For instance, [`turbo-rails`](https://github.com/hotwired/turbo-rails) decorates `ActiveRecord::Base` this way:
 
@@ -321,12 +319,10 @@ Let's suppose an engine works with the reloadable application class that models
 ```ruby
 # config/initializers/my_engine.rb
 MyEngine.configure do |config|
-  config.user_model = User # DO NOT DO THIS
+  config.user_model = User # NameError
 end
 ```
 
-On reload, `config.user_model` would be pointing to a stale object, because the reloaded `User` class would not be reset in the engine configuration. Therefore, edits to `User` would be missed by the engine.
-
 In order to play well with reloadable application code, the engine instead needs applications to configure the _name_ of that class:
 
 ```ruby