Waters mzML fileContent does not match the spectra actually written #4499

Reader_Waters::fillInMetadata builds fileDescription.fileContent by walking
FunctionIndexList() and translating each function type, independently of what the spectrum
list actually ends up containing. Because that walk is parallel to the real thing rather than
derived from it, the two drift apart in three distinct ways.

Over-declares types that were dropped. createIndex skips SIM, CNL, CNG and - without
srmAsSpectra - SRM functions, but fillInMetadata still advertises them. Reproduce with the
checked-in baseline Reader_Waters_Test.data/160109_Mix1_calcurve_070.mzML, whose <fileContent>
announces MS:1000583 SRM spectrum while the spectrum list holds none (16 MSn spectra, zero SRM).

Under-declares a type that is present. The MSe high-energy reclassification happens
per-spectrum in SpectrumList_Waters::spectrum() (the collision-energy heuristic), not in the
function-type walk, so MSe_Short.mzML contains a spectrum carrying MS:1000580 MSn spectrum and
ms level 2 while <fileContent> lists only MS1 spectrum. To be clear this is an internal
contradiction in the file, not a claim about the acquisition: Waters MSE is all-MS1 with
alternating collision energy, and pwiz chooses to present the high-energy function as MSn so
downstream tools treat it as fragment data. Having made that choice per spectrum, fileContent
should agree. No downstream misbehavior has been demonstrated for this one.

Commits before filtering. fillInMetadata runs inside Reader_Waters::read, before any
wrapping or filtering, so the answer describes the pre-filter list. msconvert with any
spectrum-dropping filter (index, msLevel, scanNumber, polarity) can therefore emit an mzML
whose fileContent advertises a type no surviving spectrum carries.

That last one matters beyond tidiness. PR #4498 makes msconvert declare
MS:1000928 calibration spectrum in fileContent precisely so a consumer can conclude from its
absence that a file has no calibration spectra, and Skyline now relies on that. A filtered output
can currently assert the positive falsely.

Driving the loop from the functions actually represented in the index - and reconciling it with the
per-spectrum reclassification - would fix all three at once, and would remove the need for the
lockmass special case PR #4498 had to add to the same loop.