Replace outdated macOS build steps with the install script

[ismetvahidzade986-sketch]

The macOS setup page still had the old manual steps, and they don't work on current macOS. The Homebrew install used the /usr/bin/ruby one-liner that Homebrew removed, and the Mojave SDK-header steps are long obsolete.

Per the discussion in #7186, this drops the manual list and points people at Tools/environment_install/install-prereqs-mac.sh, which the maintainers keep current. I kept a short note about using a virtualenv and not running things under sudo, since that trips people up.

Fixes #7186

[ES-Alexander]

I haven't tried running the script, but its functionality seems out of scope for a wiki PR (so I think that's unimportant to this review). I agree with the general idea that the prereqs script is at least more likely to be up to date than a list of manual instructions in the wiki, and this PR does seem to adequately reflect that change.

A minor gripe/confusion around the virtual environments comment. While I'm personally a fan of them to avoid messing up other parts of your system, I'm unsure how the rest of the ArduPilot dev team leans, and the comment is currently ambiguous (at least to me).

---

As something of a side note, it may be worth mentioning that it's also possible to set up using Docker for those who want to, but there are a couple of extra steps to doing so:

# Initial setup, assuming HomeBrew has already been installed
# Install Docker (to run isolated containers), and Colima (because macOS doesn't work with docker engine)
brew install docker colima
colima start  # (or `brew services start colima`, to auto-restart at login)
docker build . -t ardupilot --build-arg USER_UID=$(id -u) --build-arg USER_GID=1111

# Every time you want to do development, make sure Docker can run, and enter the ArduPilot docker container
colima start && docker run --rm -it -v "$(pwd):/ardupilot" -u "$(id -u):$(id -g)" ardupilot:latest bash

# When done, return to the normal Terminal
exit

[ES-Alexander]

I find it unclear whether this is either

1. suggesting the prereqs script will automatically install things into a virtual environment
   • This does not seem to currently be the case, from a quick read of the script
2. recommending users should create and activate a virtual environment before running the prereqs script
   • If so, there should be clearer instructions on how to do so (e.g. python3 -m venv .venv followed by source .venv/bin/activate), and how to get out of it (i.e. deactivate)

[ES-Alexander]

Perhaps worth mentioning that leaving off the -y argument allows more intentionally approving or declining each step of the process? -y is a nice convenience, but not using it provides a trust level between blind trust and manually reading and copying lines from the script.

Personally I'd prefer to let uv manage my Python versions and library installs, so I imagine others with similar inclinations may wish to avoid installing pyenv and a separate Python version without necessarily being aware of it. The script implementation details seem out of scope here - just mentioning as an example of why -y may not always be desirable.