Improve head tag parsing on template fragments

[fercomunello]

Description

This PR:

• Fix the duplication of head's children tags inside the content when parsing fragments regardless of the status of useTemplateFragments configuration.
• These modifications are applied for both parsers: template fragment and plain HTML (default). The new strategy is to skip head tag parsing on the makeFragment(response) function as head-support extension already implemented a proper merging algorithm for that.
• Added a manual .html test: hxboost_partial_template_parsing/index.html, index-partial.html & other-content.html.
• Also added an array with similar regular expressions to be compiled only once and not for every execution (edit: replaced the array approach by constants).

Corresponding issue: #2018

This PR needs a review. For knowledge: @1cg @alexpetros

Testing

• If the template fragment is parsed incorrectly and end up including head's children tags inside the template body, the manual test won't have the expected behaviour.
• In order to make the manual test fail just execute it without the modifications or uncomment the following line on htmx.js:
  content = content.replace(regexPatterns.HEAD, '');

Checklist

• I have read the contribution guidelines
• I have targeted this PR against the correct branch (master for website changes, dev for
  source changes)
• This is either a bugfix, a documentation update, or a new feature that has been explicitly
  approved via an issue
• I ran the test suite locally (npm run test) and verified that it succeeded

[alexpetros]

Overall, I think this looks great. Will try to get it slated for 1.9.10

[xhaggi]

I think this PR would benefit from #1794. It would be much easier to identify the head element, regardless of where it appears on the top level. The current implementation of makeFragment relies heavily on the order of the elements.

[fercomunello]

@xhaggi Hmm, interesting. Let's see when I've some time to playground using your PR as an entrypoint, thanks! :-)

[alexpetros]

I'll comment on #1794 but I think this PR is good. The response parser is one of the more complicated things htmx does so I can't promise we'll accept it, but this change in intelligible enough that we can at least review it.