Use rustup script instead of action in test-32bit

This fixes the following error in test-32bit, which only happens in
the i386 job:

    error: toolchain 'stable-i686-unknown-linux-gnu' may not be able to run on this system
    note: to build software for that platform, try `rustup target add i686-unknown-linux-gnu` instead
    note: add the `--force-non-host` flag to install the toolchain anyway

The command `dtolnay/rust-toolchain` ran that gave that error was:

    rustup toolchain install stable-i686-unknown-linux-gnu --profile minimal --no-self-update

As can be observed in:
https://github.com/EliahKagan/gitoxide/actions/runs/13602883937/job/38151997355

It is intentional that the test-32bit jobs use a toolchain of the
same architecture as the target, in order to test that native
builds on 32-bit platforms can be performed. This runs at, or
almost at, native speeds. This is because these are run on runners
whose 64-bit CPUs are capable of running these 32-bit binaries
directly. No software-based emulation is used.

It also seems strange that this error is produced with i386 on
x86-64, which all x86-64 CPUs are capable of, but not with arm32v7
on AArch64, which *not* all AArch64 CPUs are capable of. (Libraries
may be needed to run toolchain executables such as `rustc`, so it
makes sense that such a diagnostic might occur on both systems, but
for it to block only the i386 toolchain installation feels odd.)

It seems there is no clear reliable way to pass `--force-non-host`
through `dtolnay/rust-toolchain` when installing a toolchain. So
this replaces that action with a `curl ... | sh ...` rustup install
step and environment update step, similar to what we are already
doing in the other container test job (`pure-rust-build`), but with
the toolchain specified explicitly (for the same reason as before,
that it has sometimes been misdetected due to assuming that the
system platform matched the architecture of the running kernel).

This makes it easy to pass `--force-non-host` if we need to, but we
actually do not need to do so, seemingly due to differences between
this installation method, where the toolchain is installed at the
same time `rustup` is installed, and the subtly different method
`dtolnay/rust-toolchain` uses, where the installation script is run
without installing any toolchain, and then a toolchain is installed
in a separate `rustup` command (which is itself the command, shown
above, that would need to have `--force-non-host` on i386).

Author: EliahKagan

.github/workflows/ci.yml

@@ -53,7 +53,9 @@ jobs:
             fi
           done
       - name: Install Rust via Rustup
-        run: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --profile minimal
+        run: |
+          curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs |
+            sh -s -- -y --profile minimal
       - name: Add Rust tools to path
         run: echo "PATH=$HOME/.cargo/bin:$PATH" >> "$GITHUB_ENV"
       - name: Generate dependency tree
@@ -235,10 +237,13 @@ jobs:
           apt-get install --no-install-recommends -y -- "${prerequisites[@]}"
         shell: bash
       - uses: actions/checkout@v4
-      - uses: dtolnay/rust-toolchain@stable
-        with:
-          # Avoid possible misdetection based on the 64-bit running kernel.
-          toolchain: ${{ matrix.toolchain }}
+      - name: Install Rust via Rustup
+        run: |
+          # Specify toolchain to avoid possible misdetection based on the 64-bit running kernel.
+          curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs |
+            sh -s -- -y --default-toolchain ${{ matrix.toolchain }} --profile minimal
+      - name: Add Rust tools to path
+        run: echo "PATH=$HOME/.cargo/bin:$PATH" >> "$GITHUB_ENV"
       - uses: Swatinem/rust-cache@v2
       - uses: taiki-e/install-action@v2
         with: