Structured header parameter parser is too loose

A parameter name missing leading and/or trailing _ is accepted, probably erroneously. For example, _modifiers: a Modifiers, (as currently in proposal-regexp-modifiers spec) renders like "_modifiers (a Modifiers)" with the literal _ visible and "modifiers" not wrapped in a <var> element (as currently in proposal-regexp-modifiers HTML).

The responsible code appears to be at https://github.com/tc39/ecmarkup/blob/994d663ee9245689f4d62baaffdcbfa055d5b404/src/header-parser.ts#L140

/^[A-Za-z0-9_]+ */i should probably be replaced with /^_[A-Za-z0-9]+_ */i, or maybe /^(?:_[A-Za-z0-9]+_|[A-Za-z0-9]+) */i if we want to support parameter names not wrapped in _ (which I'd personally be against). And incidentally, I also note that the i flag is redundant with A-Za-z.

Start in src/header-parser.ts around line 140 and inspect the parameter-name regular expression. Reproduce the malformed _modifiers example and compare it with a correctly wrapped parameter name; done means malformed leading or trailing underscore forms are handled according to the chosen syntax rule without regressing valid parsing.