Use default scheduler port for LocalCluster

[tmi]

Closes #4429. I sorta pick where #4431 left off and handle the conflicting case.

In detail:

1. Unify multiple occurrences of 8786 into a single constant DEFAULT_SCHEDULER_PORT.
2. Change the default for the local cluster to use that instead of 0 (random port).
3. Introduce a fallback address for scheduler start in case of no port having been given.

The third point makes this overall more complicated, and exists just
to make the following work:

>>> c1 = LocalCluster() # starts on 8786
>>> c2 = LocalCluster() # prints warning, starts on random port

Without the third point, it would crash on port collision (unlike the current main which has the random default and thus works).
The behaviour of dask-scheduler command is not changed -- running two at once crashed before, and still crashes.

Overall this PR attempts to be unifying:

• default 8786 is more consistently used,

• port binding for dashboard and scheduler port follows the same fallbacking logic,
  while keeping the defaults "strict" for dask-scheduler command and "benevolent" for LocalCluster

• Tests added / passed

• Passes pre-commit run --all-files

[GPUtester]

Can one of the admins verify this patch?

Admins can comment ok to test to allow this one PR to run or add to allowlist to allow all future PRs from the same author to run.

[github-actions]

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

    25 files  ±0      25 suites  ±0   10h 40m 24s ⏱️ + 25m 33s
 4 130 tests ±0   4 014 ✅ + 1    110 💤 ±0   5 ❌  -  2   1 🔥 + 1 
47 708 runs  ±0  45 566 ✅  - 39  2 097 💤 +1  33 ❌ +26  12 🔥 +12 

For more details on these failures and errors, see this check.

Results for commit 1a07788. ± Comparison against base commit c3482ee.

♻️ This comment has been updated with latest results.

[tmi]

this line is what causes the test distributed/deploy/tests/test_local.py::test_Client_twice to fail, if I just comment the warning, it passes. Should I remove the warning, change it to logger invocation instead, or is there some means of making the test accept a warning occurrence?