Add opt-in support for chimeric ProForma parsing

[josiehong]

Adds opt-in parsing support for chimeric ProForma strings using chimeric=True related to #209.

This keeps the default single-sequence behavior unchanged while allowing top-level + to separate chimeric peptidoform components when explicitly requested.

Changes

• Add chimeric option to Parser, proforma.parse, and ProForma.parse.
• Return a list of parse results / ProForma objects when chimeric=True.
• Share fixed modifications, isotope labels, and peptidoform names across chimeric components.
• Preserve the current default behavior for +, with an error message suggesting chimeric=True.
• Add tests for opt-in parsing, shared metadata, empty components, charge/adduct boundaries, and shared fixed modifications.
• Document chimeric parsing and component-wise use with existing downstream APIs.

[mobiusklein]

@levitsky can you please approve workflow runs for this PR? I don't have permission.

[mobiusklein]

This bit is tricky. Names defined with > and >> are specific to a single peptidoform and peptidoform ion respectively. Only >>> names apply to all peptidoforms in the set. This is section 8.2 of the forthcoming specification: https://docs.google.com/document/d/1HaSOMNmdFCxy0G6lq1Yci03z-4esmQoe_hSyoqTeRnc/edit?tab=t.0

So AC would have the name sample, but CC would have no name.

The example from the specification is (>Trypsin)AANSIPYQVSLNS+(>Keratin)AKEQFERQTA

[mobiusklein]

This looks great other than the name sharing thing (which is trivial and can be fixed at a later date).

I'm happy to bundle that fix in with other changes when I do a coverage overhaul.