NEWS: Adjust indentation for RDoc's markdown parser

Indenting by 2 spaces wasn't yielding nested list up as intended. I guess
it's a quirk of RDoc's markdown parser:

https://github.com/ruby/rdoc/blob/v6.6.0/lib/rdoc/markdown.kpeg#L1128-L1130

    NonindentSpace =    / {0,3}/
    Indent =            /\t|    /
    IndentedLine =      Indent Line

1 files changed, 57 insertions, 57 deletions

diff --git a/NEWS.md b/NEWS.md
index 66ed7756ef..ddac290ee6 100644
--- a/NEWS.md
+++ b/NEWS.md
@@ -216,13 +216,13 @@ changelog for details of the default gems or bundled gems.
 ## Compatibility issues
 
 * Subprocess creation/forking via the following file open methods is deprecated. [[Feature #19630]]
-  * Kernel#open
-  * URI.open
-  * IO.binread
-  * IO.foreach
-  * IO.readlines
-  * IO.read
-  * IO.write
+    * Kernel#open
+    * URI.open
+    * IO.binread
+    * IO.foreach
+    * IO.readlines
+    * IO.read
+    * IO.write
 
 * When given a non-lambda, non-literal block, Kernel#lambda with now raises
   ArgumentError instead of returning it unmodified. These usages have been
@@ -236,10 +236,10 @@ changelog for details of the default gems or bundled gems.
 ## Stdlib compatibility issues
 
 * `racc` is promoted to bundled gems.
-  * You need to add `racc` to your `Gemfile` if you use `racc` under bundler environment.
+    * You need to add `racc` to your `Gemfile` if you use `racc` under bundler environment.
 * `ext/readline` is retired
-  * We have `reline` that is pure Ruby implementation compatible with `ext/readline` API. We rely on `reline` in the future. If you need to use `ext/readline`, you can install `ext/readline` via rubygems.org with `gem install readline-ext`.
-  * We no longer need to install libraries like `libreadline` or `libedit`.
+    * We have `reline` that is pure Ruby implementation compatible with `ext/readline` API. We rely on `reline` in the future. If you need to use `ext/readline`, you can install `ext/readline` via rubygems.org with `gem install readline-ext`.
+    * We no longer need to install libraries like `libreadline` or `libedit`.
 
 ## C API updates
 
@@ -270,32 +270,32 @@ changelog for details of the default gems or bundled gems.
 ### YJIT
 
 * Major performance improvements over 3.2
-  * Support for splat and rest arguments has been improved.
-  * Registers are allocated for stack operations of the virtual machine.
-  * More calls with optional arguments are compiled.
-  * Exception handlers are also compiled.
-  * Instance variables no longer exit to the interpreter
-    with megamorphic object shapes.
-  * Unsupported call types no longer exit to the interpreter.
-  * `Integer#!=`, `String#!=`, `Kernel#block_given?`, `Kernel#is_a?`,
-    `Kernel#instance_of?`, `Module#===` are specially optimized.
-  * Now more than 3x faster than the interpreter on optcarrot!
+    * Support for splat and rest arguments has been improved.
+    * Registers are allocated for stack operations of the virtual machine.
+    * More calls with optional arguments are compiled.
+    * Exception handlers are also compiled.
+    * Instance variables no longer exit to the interpreter
+      with megamorphic object shapes.
+    * Unsupported call types no longer exit to the interpreter.
+    * `Integer#!=`, `String#!=`, `Kernel#block_given?`, `Kernel#is_a?`,
+      `Kernel#instance_of?`, `Module#===` are specially optimized.
+    * Now more than 3x faster than the interpreter on optcarrot!
 * Significantly improved memory usage over 3.2
     * Metadata for compiled code uses a lot less memory.
     * Generate more compact code on ARM64
 * Compilation speed is now slightly faster than 3.2.
 * Add `RubyVM::YJIT.enable` that can enable YJIT later
-  * You can start YJIT without modifying command-line arguments or environment variables.
-  * This can also be used to enable YJIT only once your application is
-    done booting. `--yjit-disable` can be used if you want to use other
-    YJIT options while disabling YJIT at boot.
+    * You can start YJIT without modifying command-line arguments or environment variables.
+    * This can also be used to enable YJIT only once your application is
+      done booting. `--yjit-disable` can be used if you want to use other
+      YJIT options while disabling YJIT at boot.
 * Code GC now disabled by default, with `--yjit-exec-mem-size` treated as a hard limit
-  * Can produce better copy-on-write behavior on forking web servers such as `unicorn`
-  * Use the `--yjit-code-gc` option to automatically run code GC when YJIT reaches the size limit
+    * Can produce better copy-on-write behavior on forking web servers such as `unicorn`
+    * Use the `--yjit-code-gc` option to automatically run code GC when YJIT reaches the size limit
 * `ratio_in_yjit` stat produced by `--yjit-stats` is now available in release builds,
   a special stats or dev build is no longer required to access most stats.
 * Exit tracing option now supports sampling
-  * `--trace-exits-sample-rate=N`
+    * `--trace-exits-sample-rate=N`
 * More thorough testing and multiple bug fixes
 * `--yjit-stats=quiet` is added to avoid printing stats on exit.
 * `--yjit-perf` is added to facilitate profiling with Linux perf.
@@ -303,45 +303,45 @@ changelog for details of the default gems or bundled gems.
 ### MJIT
 
 * MJIT is removed.
-  * `--disable-jit-support` is removed. Consider using `--disable-yjit --disable-rjit` instead.
+    * `--disable-jit-support` is removed. Consider using `--disable-yjit --disable-rjit` instead.
 
 ### RJIT
 
 * Introduced a pure-Ruby JIT compiler RJIT.
-  * RJIT supports only x86\_64 architecture on Unix platforms.
-  * Unlike MJIT, it doesn't require a C compiler at runtime.
+    * RJIT supports only x86\_64 architecture on Unix platforms.
+    * Unlike MJIT, it doesn't require a C compiler at runtime.
 * RJIT exists only for experimental purposes.
-  * You should keep using YJIT in production.
+    * You should keep using YJIT in production.
 
 ### M:N Therad scheduler
 
 * M:N Thread scheduler is introduced. [[Feature #19842]]
-  * Background: Ruby 1.8 and before, M:1 thread scheduler (M Ruby threads
-    with 1 native thread. Called as User level threads or Green threads)
-    is used. Ruby 1.9 and later, 1:1 thread scheduler (1 Ruby thread with
-    1 native thread). M:1 threads takes lower resources compare with 1:1
-    threads because it needs only 1 native threads. However it is difficult
-    to support context switching for all of blocking operation so 1:1
-    threads are employed from Ruby 1.9. M:N thread scheduler uses N native
-    threads for M Ruby threads (N is small number in general). It doesn't
-    need same number of native threads as Ruby threads (similar to the M:1
-    thread scheduler). Also our M:N threads supports blocking operations
-    well same as 1:1 threads. See the ticket for more details.
-    Our M:N thread scheduler refers on the gorotuine scheduler in the
-    Go language.
-  * In a ractor, only 1 thread can run in a same time because of
-    implementation. Therefore, applications that use only one Ractor
-    (most applications) M:N thread scheduler works as M:1 thread scheduler
-    with further extension from Ruby 1.8.
-  * M:N thread scheduler can introduce incompatibility for C-extensions,
-    so it is disabled by default on the main Ractors.
-    `RUBY_MN_THREADS=1` environment variable will enable it.
-    On non-main Ractors, M:N thread scheduler is enabled (and can not
-    disable it now).
-  * `N` (the number of native threads) can be specified with `RUBY_MAX_CPU`
-    environment variable. The default is 8.
-    Note that more than `N` native threads are used to support many kind of
-    blocking operations.
+    * Background: Ruby 1.8 and before, M:1 thread scheduler (M Ruby threads
+      with 1 native thread. Called as User level threads or Green threads)
+      is used. Ruby 1.9 and later, 1:1 thread scheduler (1 Ruby thread with
+      1 native thread). M:1 threads takes lower resources compare with 1:1
+      threads because it needs only 1 native threads. However it is difficult
+      to support context switching for all of blocking operation so 1:1
+      threads are employed from Ruby 1.9. M:N thread scheduler uses N native
+      threads for M Ruby threads (N is small number in general). It doesn't
+      need same number of native threads as Ruby threads (similar to the M:1
+      thread scheduler). Also our M:N threads supports blocking operations
+      well same as 1:1 threads. See the ticket for more details.
+      Our M:N thread scheduler refers on the gorotuine scheduler in the
+      Go language.
+    * In a ractor, only 1 thread can run in a same time because of
+      implementation. Therefore, applications that use only one Ractor
+      (most applications) M:N thread scheduler works as M:1 thread scheduler
+      with further extension from Ruby 1.8.
+    * M:N thread scheduler can introduce incompatibility for C-extensions,
+      so it is disabled by default on the main Ractors.
+      `RUBY_MN_THREADS=1` environment variable will enable it.
+      On non-main Ractors, M:N thread scheduler is enabled (and can not
+      disable it now).
+    * `N` (the number of native threads) can be specified with `RUBY_MAX_CPU`
+      environment variable. The default is 8.
+      Note that more than `N` native threads are used to support many kind of
+      blocking operations.
 
 [Bug #17146]:     https://bugs.ruby-lang.org/issues/17146
 [Feature #18183]: https://bugs.ruby-lang.org/issues/18183