Test-library fixes: overridable kernel start timeout, and a batching-proof diagnostic assertion

[thomasjm]

Two test-library changes, after splitting the Rust startup problem out to #105.

Overridable kernel start timeout

--start-timeout was hardcoded at 120 in runKernelCode. runKernelCode and
notebookShouldSatisfy now take it, defaultStartTimeout = 120 keeps every existing caller
unchanged, and testKernelSucceeds' is there for kernels that legitimately need longer.

Nothing uses the override yet. The case that motivated it — the Rust data science kernel spending
~115s compiling crates on every start — is better fixed by not doing the work at all, which is #105.
Raising the global default instead would have made every hung kernel take five times longer to
report, so the machinery is worth having either way.

test.rs with missing struct field

Fails in CI, passes locally. Two sources publish diagnostics for that file and only one of them is
dependable, so the test asserts on that one:

assertDiagnosticRangesFromSource' "rustc" ... [ E0063 "missing field `b` ..." ]

rustc's diagnostic, via flycheck, was identical in every run I did. rust-analyzer's own two
(non_upper_case_globals and its own E0063) come and go: in some runs it never links the detached
file into the crate graph and publishes none of its own at all. I confirmed that by running with an
assertion that never matches, so the watcher stays up for the whole timeout — one run published
[], [], [rustc] and then nothing further for 60s.

Asserting the full set therefore can't be stable however it's gathered, and it isn't a question of
waiting longer. Filtering by source keeps the assertion exact — an unexpected or missing rustc
diagnostic still fails it — while dropping coverage we didn't really have.

publishDiagnostics carries the complete set per URI and replaces the previous one, so there's no
partial state to accumulate; lsp-test already tracks the current set. The variability is in what
the server publishes, not in how we collect it.

Testing

Compiles clean, and the test passes. Checked it isn't vacuous: adding a diagnostic to the expected
list that no server publishes makes it fail, as it should.

Note

This no longer touches Spec/Tests/Rust.hs, so it won't conflict with #105. It also no longer fixes
rust -- use polars... on its own — #105 does that.