Some updates to scheduling policies docs

[gjoseph92]

I was reading through the scheduling policy docs and noticed some things were outdated or missing important details. I think it could still benefit from a bigger revamp, but makes it a bit more accurate.

cc @fjetter @crusaderky

• Closes #xxxx
• Passes pre-commit run --all-files

[github-actions]

Unit Test Results

       12 files  ±       0         12 suites  ±0   5h 50m 30s ⏱️ - 1h 29m 1s
  2 653 tests +     30    2 570 ✔️ +     30    80 💤 ±    0  3 ❌ ±0 
13 021 runs   - 2 641  12 380 ✔️  - 2 417  637 💤  - 225  4 ❌ +1 

For more details on these failures, see this check.

Results for commit 641f3b7. ± Comparison against base commit 39c5e88.

♻️ This comment has been updated with latest results.

[crusaderky]

short of avoiding disk spillage, why would it result in a shorter runtime?

[gjoseph92]

I didn't write this, really not sure. Maybe just that depth-first traversal is faster than breadth-first traversal (simply because it has a reduced memory footprint)? I feel like it might be referring to something about when multiple clients are submitting work, completing the work of one, rather than fully interleaving them, results in better overall runtimes (again because of reduced memory footprint)?

[crusaderky]

It says that it does in fact go against first-come-first-served expectations.
Maybe change to:

but often results in significantly reduced memory footprints and, due to avoiding data spillage to disk, often in better overall runtimes.

[gjoseph92]

@crusaderky I believe this is ready

[crusaderky]

Thank you!