Don't use Homebrew outside of MacOS

In Linux, it's not the primary source of packages and
cannot be used without build flag adjustments
thus has caused build failures.

Simplify init scheme

We're going to eliminate the need to mandatorily use `pyenv init --path`.
We can't delete it yet for backward compatibility.
Besides, there's one other use case for it: to enable shims but without
shell integration, e.g. for noninteractive shells.

To be a full-fledged replacement for `pyenv init -` however,
it needs to do rehashing.

Now the setup is to add to both rc and profile:
1) set PYENV_ROOT
   (can do it unconditionally -- since if you change it,
   you need to update all places anyway since any of them can be run first)
2) Add `pyenv` to PATH if not already there
3) eval "$(pyenv init -)"

Not a breaking change, old setup will continue to work.

Required for diagnostics

Trace logs without `-v` are usually useless due to missing the build part.
So this leaves one less thing for users to worry about
when submitting error reports.

Mentioning `-v` in the issue template should stay for some time
since users report on old versions, too.

There are no new (glaring) platform incompatibilities in MacOS 12 so those releases should technically run in it as well

Co-authored-by: Dan Dees <dand@appsmiths.com>

I've never been able to activate (or refund) existing bounties on solved problems. Their support has been unhelpful. So I've given up on them.

Fixes https://github.com/pyenv/pyenv/issues/2278

All the patches still apply

Co-authored-by: Dan Dees <dand@appsmiths.com>

This reverts commit 90d0d20508.

After further consideration, we've decided to remove this workaround:
* It only has an effect if the user has added `gnubin` from Homebrew Coreutils to PATH which is an unsupported setup
* It was intended to be applied only to a few select 3.8 and 3.9 versions that officially support Apple Silicon and only fail with Homebrew Coreutils in PATH because they have `config.*` from a too old version of Autoconf that doesn't support the Arm64 arch -- but
  * CPython devs [didn't actually fix the problem in 3.10, either, only in 3.11](https://github.com/pyenv/pyenv/pull/2157#issuecomment-968055387), so we'd need to apply it to all 3.10 releases, too
  * users started pushing this workaround into other unrelated branches because they were using the above unsupported setup. See https://github.com/pyenv/pyenv/pull/2190#pullrequestreview-835221952 for discussion.

In my previous work on getting Python 3.6.15 and 3.7.12 to compile on
Apple M1, I backported logic from newer 3.8.x releases to properly find
libffi and related files on macOS.

This regressed compilation on Linux. The include search path was
incomplete, and `ffi.h` could not be found, resulting in `ctypes` being
disabled.

There was a key difference between the old logic and new logic that led
to this regression:

1. In 3.8 and newer, `detect_ctypes()` in `setup.py` took no arguments,
   and was expected to access instance variables for the include search
   path.
2. In 3.7 and earlier, `detect_ctypes()` took the path as an argument,
   and was expected to make use of it.

The backport made use of the instance variables, overriding the provided
include path. These were not equivalent. The one on the instance was not
complete, lacking the necessary directories to find `ffi.h`. Since this
could not be found, `ctypes` support was disabled.

The fix is to simply not overwrite the variables passed to the function,
and resume using them as before.

Fixes #2207