chore: update fast-xml-parser to 5.8.0 🏠

[mcdurdin]

Cherry-picked from dependabot PR on 19.0 alpha, and adjusted for 18.0.

Test-bot: skip
Cherry-pick-of: #15868

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

[ermshiperete]

package-lock.json has 5.8.0, so I'm wondering if we should put that version in here as well?

[mcdurdin]

Tested and verified with 5.8.0, updated.

[ermshiperete]

From devin.ai - might be worth a look:

Pre-existing: kvks tagValueProcessor returns null with intent of 'no change'

The kvks tagValueProcessor at developer/src/common/web/utils/src/xml-utils.ts:73 returns null for leaf nodes with the comment // no change to leaf nodes. In fast-xml-parser, the conventional way to signal 'no change' from a tagValueProcessor is typically to return undefined, not null. Returning null may cause leaf node values to be set to the literal value null rather than preserving the original value. This was pre-existing behavior (unchanged by this PR), but the library upgrade from 5.0.9 to 5.8.0 could theoretically change how null return values are handled internally. Worth verifying via the test suite that kvks parsing output hasn't changed.

[mcdurdin]

Seems to be fine, all tests passing

[ermshiperete]

From devin.ai:
keyboard3 tagValueProcessor not updated for new API signature

The keyboard3 config's tagValueProcessor at line 44 still has the extra parameters commented out (/*, jPath, hasAttributes, isLeafNode*/), while the kvks config was updated to use the new JPathOrMatcher type for the third parameter. This is technically fine since JavaScript allows callbacks to declare fewer parameters than provided, but it's inconsistent — one processor was updated and the other wasn't. If someone later uncomments those parameters, they'd need to use the new types.

Suggested change

	tagValueProcessor: (_tagName: string, tagValue: string /*, jPathOrMatcher, hasAttributes, isLeafNode*/) => {