serverbase: only collect when something was allocated

[BaruchWeka]

A bare timer made an idle server re-mark an unchanged heap every interval,
using CPU and waking every core. Gate it on gcCollectMinAllocated, plus one
collection once the server goes quiet.

(cherry picked from commit bf96205d736e23429d65cee13de9b41565e80b88)

[BaruchWeka]

CI note: the only red job here, Dub Tests (macos-latest, ldc-latest), fails in test/runtests.sh at tc_implement_interface, which dies with Program exited with code -11 (SIGSEGV) and no output. I don't believe it's related to this PR:

• test-implement-interface resolves only serve-d:workspace-d and serve-d:dcd (per the dependency listing in the job log). This PR touches serverbase/source/served/serverbase.d, lsp/source/served/lsp/filereader.d and lsp/source/served/lsp/jsonrpc.d — none of which are compiled
  into that binary.
• The steps that do exercise the changed code are green on that same macOS runner: serverbase tests, build minimal server, test minimal server, Run tests, and tc_as_a_exe (which runs the serve-d binary runtests.sh just built).
• I pushed three independent branches within a minute of each other: filereader: don't allocate on every yieldLine call #426 passed on macOS, while jsonrpc: allow a timeout on requestMessage, use it for the DCD prompt #425 and serverbase: only collect when something was allocated #427 both failed with the identical tc_implement_interface code -11. The resolved dependency versions in the passing and failing macOS jobs are identical across all 19
  packages, and both downloaded dcd-v0.16.2-osx-aarch64 fresh — so the inputs to that test were the same in both.
• Base is 6369a75 (master), whose own run on Jul 19 was green on macOS.

Timing hints the crash is at or near teardown: the passing run takes 11.2 s and flushes all seven Pass tests/*.expected lines at exit, the failing one dies at 9.8 s with nothing flushed (stdout is block-buffered, so a crash loses the lot).

For what it's worth, #422 also hit Run standalone tests failing macOS-only, twice, in June — its logs have expired so I can't confirm it was the same test case.

Could you re-run the macOS job? I don't have permission to. Otherwise I'm happy to push an empty commit to re-trigger it. The same applies to #425.