Fix incorrect examples and typos in guides (#15620)

The guide pages under lib/elixir/pages are not doctests, so some
example outputs drifted from what current Elixir prints. I re-ran
each example on main (1.21.0-dev, OTP 29) with a clean IEx and
updated the blocks to match the actual output. Also fixes two typos.
Map ordering examples were left untouched since small-map print
order is not guaranteed across OTP versions.

Signed-off-by: Patric Vinicios <psdev7@gmail.com>

Author: patric-vinicios

lib/elixir/pages/anti-patterns/code-anti-patterns.md

@@ -197,7 +197,7 @@ iex> MyRequestHandler.parse(%{"status" => "status_not_seen_anywhere", "message"
 
 By explicitly listing all supported statuses, you guarantee that only a limited number of conversions may happen, and that all expected atoms already exist within the system.
 
-An alternative is to use pattern matching and explicitly convert each string to its respective atom. This is useful when you need additional logic on differnt branches:
+An alternative is to use pattern matching and explicitly convert each string to its respective atom. This is useful when you need additional logic on different branches:
 
 ```elixir
 defmodule MyRequestHandler do

lib/elixir/pages/anti-patterns/process-anti-patterns.md

@@ -144,7 +144,7 @@ iex> C.update(agent)
 
 # state of shared information
 iex> D.get(agent)
-[:atom_value, %{a: 123}]
+[:atom_value | %{a: 123}]
 ```
 
 For a `GenServer` and other behaviours, this anti-pattern will manifest when scattering calls to `GenServer.call/3` and `GenServer.cast/2` throughout multiple modules, instead of encapsulating all the interaction with the `GenServer` in a single place.

lib/elixir/pages/getting-started/sigils.md

@@ -214,7 +214,7 @@ As hinted at the beginning of this chapter, sigils in Elixir are extensible. In
 
 ```elixir
 iex> sigil_r(<<"foo">>, [?i])
-~r"foo"i
+~r/foo/i
 ```
 
 We can access the documentation for the `~r` sigil via `sigil_r`:

lib/elixir/pages/meta-programming/macros.md

@@ -46,7 +46,7 @@ iex> require Unless
 iex> Unless.macro_unless(true, do: IO.puts("this should never be printed"))
 nil
 iex> Unless.fun_unless(true, do: IO.puts("this should never be printed"))
-"this should never be printed"
+this should never be printed
 nil
 ```
 
@@ -81,7 +81,7 @@ We can actually verify that this is the case by using `Macro.expand_once/2`:
 iex> expr = quote do: Unless.macro_unless(true, do: IO.puts("this should never be printed"))
 iex> res  = Macro.expand_once(expr, __ENV__)
 iex> IO.puts(Macro.to_string(res))
-if(!true) do
+if !true do
   IO.puts("this should never be printed")
 end
 :ok
@@ -214,11 +214,11 @@ nil
 iex> __ENV__.file
 "iex"
 iex> __ENV__.requires
-[IEx.Helpers, Kernel, Kernel.Typespec]
+[Application, IEx.Helpers, Kernel]
 iex> require Integer
-nil
+Integer
 iex> __ENV__.requires
-[IEx.Helpers, Integer, Kernel, Kernel.Typespec]
+[Application, IEx.Helpers, Integer, Kernel]
 ```
 
 Many of the functions in the `Macro` module expect a `Macro.Env` environment. You can read more about these functions in `Macro` and learn more about the compilation environment in the `Macro.Env`.

lib/elixir/pages/meta-programming/quote-and-unquote.md

@@ -28,7 +28,7 @@ Operators are also represented as such tuples:
 
 ```elixir
 iex> quote do: 1 + 2
-{:+, [context: Elixir, import: Kernel], [1, 2]}
+{:+, [context: Elixir, imports: [{1, Kernel}, {2, Kernel}]], [1, 2]}
 ```
 
 Even a map is represented as a call to `%{}`:
@@ -49,7 +49,8 @@ When quoting more complex expressions, we can see that the code is represented i
 
 ```elixir
 iex> quote do: sum(1, 2 + 3, 4)
-{:sum, [], [1, {:+, [context: Elixir, import: Kernel], [2, 3]}, 4]}
+{:sum, [],
+ [1, {:+, [context: Elixir, imports: [{1, Kernel}, {2, Kernel}]], [2, 3]}, 4]}
 ```
 
 Sometimes, when working with quoted expressions, it may be useful to get the textual code representation back. This can be done with `Macro.to_string/1`:

lib/elixir/pages/references/gradual-set-theoretic-types.md

@@ -266,7 +266,7 @@ user = find_user_by_id(42)
 %User{user | name: "John Doe"}
 ```
 
-Even though it is guaranteed at runtime that user is always a `User` struct. If the type system cannot prove it, it will emit a typing violation. This is how stuct updates work by design. In such cases, you can address it by matching on the struct when the user variable is defined:
+Even though it is guaranteed at runtime that user is always a `User` struct. If the type system cannot prove it, it will emit a typing violation. This is how struct updates work by design. In such cases, you can address it by matching on the struct when the user variable is defined:
 
 ```elixir
 %User{} = user = find_user_by_id(42)