docs: update changelog for 0.28.0 release (bazel-contrib#1672)

This is to prepare for the 0.28.0 release.

fix: register autodetecting toolchain automatically

@bazel_tools depends on rules_python, but the version is currently
specifies (0.22.0) doesn't register a toolchain by default. This means
the Bazel builtin Python rules aren't usable because no toolchain
is registered for them.

Registering the toolchain directly in @bazel_tools inverts the problem:
a toolchain is now always registered, but will usually always have
precedence over any that rules_python registers (because @bazel_tools
typically comes earlier in the module graph ordering).

Upgrading bazel_tools past to 0.23.0 or higher (which register a Python
toolchain automatically) is possible, but results in many failures in
Bazel CI that are hard to figure out.

To fix, we make rules_python register the autodetecting toolchain.
Later rules_python versions register a different toolchain, but this
at least gives Bazel something it can set as the minimum version that
preserves existing behavior.

Work towards bazelbuild/bazel#20458

fix(gazelle): ensure that gazelle helper modules are on PYTHONPATH (b…

…azel-contrib#1590)

Before this change there was a bug in how the parsing helpers were being
used in case we were using Python 3.11 toolchain, which is using a more
strict version of the entrypoint template. This change adds `imports =
["."]`
to ensure that the gazelle helper components are on PYTHONPATH and
updates
the non-bzlmod tests to run under 3.11.

We also:
* Change `.bazelrc` to use explicit `__init__.py` definition to avoid
  non-reproducible errors in the future.
* Add a dedicated `gazelle_binary` that uses `DEFAULT_LANGUAGES` *and*
  `//python`.

Fixes bazel-contrib#1589

fix(gazelle): make cmd.Wait more idiomatic (bazel-contrib#1550)

It seems that the documentation for the `cmd.Wait` explicitly
asks the users to not wait on the command immediately after
starting because it may close pipes too early and cause
unintended side-effects as described in bazel-contrib#1546.

Fixes bazel-contrib#1546.

Co-authored-by: Richard Levasseur <rlevasseur@google.com>

chore: add new Python toolchains from indygreg (bazel-contrib#1461)

Updates versions:
* 3.8.15  -> 3.8.18
* 3.11.4  -> 3.11.6

Adds versions: 3.8.18, 3.11.6, 3.12.0

Fixes bazel-contrib#1396

Update changelog for 0.25.0 (bazel-contrib#1389)

This is to prepare for the 0.25.0 release.

cleanup(tests): Use new APIs in rules_testing 0.4.0 (bazel-contrib#1307)

* Use public APIs for DictSubject and StrSubject.
* Use rules_testing's StructSubject instead of our own.

Work towards 1297

fix(bzlmod+gazelle): update BCR release presubmit to use correct exam…

…ple (bazel-contrib#1264)

The bzlmod-compatible build_file_generation example was moved to the
bzlmod_build_file_generation example.

This should fix the automatic build/release of the gazelle BCR module.

feat(bzlmod): Register a default toolchain (bazel-contrib#1259)

This makes rules_python always provide a default toolchain when using
bzlmod.

Note that, unlike workspace builds, the default is not the local
system Python (`@bazel_tools//tools/python:autodetecting_toolchain`).

Instead, the default is a hermetic runtime, but no guarantees are made
about the particular version used. In practice, it will be the latest
available Python version.

Work towards bazel-contrib#1233

feat(bzlmod): support entry_point macro (bazel-contrib#1220)

Add `entry_point` macro to the repo generated by the `pip.parse`
extension.
This works by using the canonical label literal, so should work without
users
needing to add the spoke repos to the `use_repo` statement. We test this
by
having an extra folder in the `bzlmod` example.

Fixes bazel-contrib#958.