Proposal: Make Keyword & Json-Query generic across monitor types

[chakflying]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Fixes #2439
Fixes #1851
Fixes #3336
Fixes #2342
Fixes #3844
Fixes #3140

After working on #3857, it became obvious to me that the use of Keyword or Json-Query result matching would benefit many other monitor types, e.g. SQL query results, DNS results. It is also obvious that implementing them individually for each monitor type would lead to a lot of code duplication and issues with maintainability.

Given that we are migrating the code base to where each monitor type is its own file and has a self-contained check function, I think we can take one step further by refactoring them such that:

• For each monitor type, the check function performs the actions required for each heartbeat. This function should return a string or object if successful. If it fails at any stage, it can throw an Error as it does currently.
• If the check function is successful and returns a value, it can be passed to the verify stage, which would be independent of monitor types. We can reuse the code for Keyword and Json-Query, and test for positive results accordingly. This function then also produce a success or fail message.
• Finally, based on the results of the check and verify functions, we can set the status of the heartbeat, while handling retries, upsideDown, and resentNotification. This part should be identical to the current implementation.

By making the verify part generic, we can remove the need for the separate monitor type HTTP - Keyword, and expand the ability of checking for results to any monitor types that can produce a string or object.

However, this would involve quite a big refactor of the monitor.js file, and possibly need to handle migrations for existing users of the Keyword monitor types.

Type of change

• User interface (UI)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas
  (including JSDoc for methods)
• My changes generate no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

[louislam]

Yes, agree with that. However it is definitely a big changes of core features. I hope this pr should depend on #3893. Hopefully Playwright's codegen and recorder could assist me to create e2e tests easily and quickly.