feat: support multiline patterns in switch rule conditions

[rz467fzs7d]

Summary

Allow users to enter multiple patterns in a single switch rule condition, separated by newlines (in addition to the existing pipe | separator).

Changes

omega-pac/src/conditions.coffee

• HostWildcardCondition, UrlWildcardCondition, HostRegexCondition, UrlRegexCondition now split patterns by both | and newline \n

omega-web/src/partials/profile_switch.jade

• Replace single-line input with an expandable textarea (1 row collapsed, 10 rows expanded)
• Toggle button to expand/collapse
• Single-line mode blocks Enter key; auto-expands on click when multiline content exists

omega-web/src/omega/controllers/switch_profile.coffee

• Add isMultiline() helper
• validateCondition validates each line independently for regex types

Notes

The pre-existing SOCKS5 test failure (should return special compatible result for SOCKS5) exists on master and is unrelated to this change.

[rz467fzs7d]

• HostWildcardCondition, UrlWildcardCondition, HostRegexCondition, UrlRegexCondition now accept newline-separated patterns in addition to pipe-separated ones
• Replace pattern input with expandable textarea (1 row collapsed, 10 rows expanded) with toggle button
• Single-line mode blocks Enter key and auto-expands on click when multiline content exists
• validateCondition validates each line independently for regex types

What does this PR do?

• Improvement

(Note: Translations and typo fixes should be done on https://hosted.weblate.org/projects/switchyomega/ instead of PR.)

Please explain the changes in details here...
HostWildcardCondition, UrlWildcardCondition, HostRegexCondition, UrlRegexCondition now accept newline-separated patterns in addition to pipe-separated ones

Compatibility

Is this PR compatible with old versions? Can users simply upgrade the extension?
Yes

Please describe any possible breaking changes (or surprising UX differences).

Screenshots (if applicable)

---

After creating the PR:

• Please make sure the CircleCI test passes. Feel free to add more commits for
  bug or style fixes.
• Any merge conflicts should be fixed on your side. Prefer rebasing to merging.
• Allow some time for project maintainers to review and merge the change.
• New features & behavior changes are subject to discussion. Please understand
  that project maintainers may reject new features, or request changes.