Docs communicates anyio_backend is function scoped, but it's actually module scoped

[EmmanuelNiyonshuti]

NOTE Erasing or replacing the contents of this template will result in your pull
request being summarily closed without consideration!

Changes

Related to ##1156

I got a little hesitant here because reverting anyio_backend back to function scoped
doesn't break anyio's own test suite. I suspected this was because the 3.x backport
#437 (backporting the async-generator-fixture
change from #435) explicitly added anyio_backend as module scoped directly inside
test_pytest_plugin.test_module_scoped_task_group_fixture:

anyio/tests/test_pytest_plugin.py

Lines 273 to 275 in 85b8b6e

	@pytest.fixture(scope="module", params=get_available_backends())
	def anyio_backend():
	return 'asyncio'

What I took this to imply was that anyio_backend had stayed function scoped, except it was already updated to module scoped in #435 , hence redeclaring it as module scoped explicitly in that one test doesn't seem to change anything.

Best I can tell, having anyio_backend module scoped by default reduces the boilerplate for higher-scoped async/async-generator fixtures.

Another tiny confusion was that, there are two fixtures that depend on
anyio_backend for convenience,
https://anyio.readthedocs.io/en/stable/testing.html#:~:text=Because%20the%20anyio_backend,run%20the%20backend

anyio/src/anyio/pytest_plugin.py

Lines 281 to 282 in 85b8b6e

	@pytest.fixture
	def anyio_backend_name(anyio_backend: Any) -> str:

anyio/src/anyio/pytest_plugin.py

Lines 289 to 290 in 85b8b6e

	@pytest.fixture
	def anyio_backend_options(anyio_backend: Any) -> dict[str, Any]:

and these were left function scoped. But, I don't think this a problem?. These fixtures aren't auto-injected into async fixtures like anyio_backend is; they're only pulled in when someone deliberately requests them.

And updating the docs seemed to make more sense to me than reverting anyio_backend back to
function scoped, unless I'm proven wrong.

Checklist

If this is a user-facing code change, like a bugfix or a new feature, please ensure that
you've fulfilled the following conditions (where applicable):

• You've added tests (in tests/) which would fail without your patch
• You've updated the documentation (in docs/), in case of behavior changes or new
  features
• You've added a new changelog entry (in docs/versionhistory.rst).

If this is a trivial change, like a typo fix or a code reformatting, then you can ignore
these instructions.

Updating the changelog

If there are no entries after the last release, use **UNRELEASED** as the version.
If, say, your patch fixes issue #123, the entry should look like this:

- Fix big bad boo-boo in task groups
  (`#123 <https://github.com/agronholm/anyio/issues/123>`_; PR by @yourgithubaccount)

If there's no issue linked, just link to your pull request instead by updating the
changelog after you've created the PR.