Feat: Improve TLS certificate display & handling

[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 #3551

• The previous method of obtaining the certificate information after response is processed is not reliable. I suspect this is because if the server does not keep the TCP connection alive, the socket might be gone by the time we try to get info from it. Listening for the keylog event should be more reliable.
• Unfortunately, during the keylog event, whether the connection is valid and secure is not defined. Ideally we would listen for the secureConnect event for this, but using axios there does not seem to be a way to do this. Hence it is manually checked in the previous location.
• Add handling for the authorizationError information and display it in the UI.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• User interface (UI)
• New feature (non-breaking change which adds functionality)

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 generates no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

[CommanderStorm]

More as a discussion point: Should this be backported or are there any breaking changes that I am not seeing
=> should this PR be based on the 1.23.X branch or should this be treated as a feature?

[chakflying]

The authorizationError part is a minor new feature. I can make a branch without that part for backporting if needed.

[CommanderStorm]

I can make a branch without that part for backporting if needed.

I would prefer if you were to split this PR into the 1.23.X part and the 2.x part.
This way there won't be such a huge merge conflict ^^