fix(customParseFormat): match MMM/MMMM against locale month names

[xianjianlf2]

Problem

When parsing with customParseFormat, the generic "word" regex used for the MMM/MMMM month-name tokens excludes the -_:/,() separators and whitespace, but not .. As a result, an input like dayjs('29.Jul.2021', 'DD.MMM.YYYY') caused the month token to greedily capture Jul. (swallowing the trailing separator dot), which matches no month name and produced an Invalid Date. This is a regression from older versions and a divergence from moment, which parses the same input correctly.

Fix

Rather than naively adding . to the exclusion list (which would break locales whose short month names legitimately contain a dot, e.g. gl's xan.), MMM/MMMM now match against the actual locale month names, sorted longest-first. Because the captured value is now exactly one of the real month names, it can no longer swallow a trailing separator, while dotted month names continue to parse correctly.

Changes in src/plugin/customParseFormat/index.js:

• Added an escapeRegExp helper.
• Added matchMonthName(token) which builds a regex from the active locale's months (for MMMM) or monthsShort (for MMM, falling back to the first 3 chars of months), escaped and joined longest-first.
• The parser now uses this month-name regex for the MMM/MMMM tokens instead of the generic word regex.

Testing

Added tests in test/plugin/customParseFormat.test.js:

• 29.Jul.2021 with DD.MMM.YYYY parses to 2021-07-29 and matches moment.
• 29.July.2021 with DD.MMMM.YYYY parses to 2021-07-29 and matches moment.
• gl locale short month containing a dot (xan.) parses correctly with both dot and space separators (29.xan..2021 / 29 xan. 2021 → 2021-01-29).

Closes #2818