fix(PyRuntimeInfo): use builtin PyRuntimeInfo unless pystar is enabled.

[rickeylev]

This fixes the bug where the PyRuntimeInfo symbol rules_python exported wasn't matching the provider identity that py_binary actually provided.

The basic problem was, when pystar is disabled:

• PyRuntimeInfo is the rules_python defined provider
• py_binary is native.py_binary, which provides only the builtin PyRuntimeInfo provider.

Thus, when users loaded the rules_python PyRuntimeInfo symbol, it was referring to a provider that the underlying py_binary didn't actually provide. Pystar is always disabled on Bazel 6.4,
and enabling it for Bazel 7 will happen eminently.

This typically showed up when users had a custom rule with an attribute definition that used the rules_python PyRuntimeInfo.

To fix, only use the rules_python define PyRuntimeInfo if pystar is enabled. This ensures the providers the underlying rules are providing match the symbols that rules_python is exported.

• Also fixes py_binary and py_test to also return the builtin PyRuntimeInfo. This
  should make the transition from the builtin symbols to the rules_python symbols a bit
  easier.

Fixes #1732

[rickeylev]

Ah hm, looks like the pystar config isn't happy with this. I'll put this back into draft and figure out what's going on.

[rickeylev]

Tests fix. PTAL.

It uncovered another gap in compatibility: pystar py_binary wasn't returning the builtin PyRuntimeInfo. It does now, which should allow it to (1) work with a builtin py_runtime defined toolchain, and (2) allow it to work with code that is expecting the builtin PyRuntimeInfo (i.e. users that aren't loading from rules_python).