Settings: Allow user to manually set RTC per-game

[TheTechnician27]

Description of Changes

Allows the user the option to manually input a date and time for the PlayStation 2's real-time clock rather than 2020-04-03 00:00:00 for input recording and the OS' system clock otherwise. Only works if the BIOS is set to a region which is GMT+0 and DST is Summer Time (which is the default PCSX2 uses).

Rationale behind Changes

Multiple games have mechanics that play with the real-time clock.

• Tool-assisted speedrunners may want the ability to designate an arbitrary start date and time for RNG purposes.
• Some games make use of the date for an in-game event, such as Scooby-Doo! Night of 100 Frights' multiple holidays.
• Some games make use of the advancement of real time for an in-game event, such as The End's boss fight in Metal Gear Solid 3.
• Some games make use of the time for an in-game event, for example Ratchet 2 and 3 which have a teleporter to the Insomniac Museum in the dead of night.
• Because we can.
• Closes [Feature Request] System time and date fetching #4491.

Suggested Testing Steps

• Make sure you can't access this from the global settings, only per-game.
• Make sure this setting persists with reboots.
• Make sure you can't go beyond the bounds of 2000-01-01 and 2099-12-31.
• Make sure (using aforementioned BIOS defaults) that the date and time in games corresponds to the time you set on the clock. (I've tested this in the BIOS to confirm minutes and seconds work, but you might not be able to get that granular.)
• Make sure the tool tips are free of typos and adequately convey the information.

Screenshots

Tested on 2005-03-09 03:04:05

[GovanifY]

Quick check, been a while since I have done a review on the emulator, so feel free to correct me if I'm being a dumbass :)

[GovanifY]

SECTION.c_str() is 15 characters whereas "EmuCore" is 9 with quotes, making it not only clearer if we use it directly but also shorter.
Is there any reason that we define all those entries manually? It would be handy if we wanted to rename them, but besides that unsure of whether the added verbosity is worth it.
Also, if we keep them this way, a define might be worth it to avoid the cast to c_str

[TheTechnician27]

This wrapper already does a lot of hard-coding, but I'm thinking I'm going to un-hardcode SECTION in case this ever becomes an option for input recording specifically, since I intend to expand the capabilities of input recording in the future (including making a separate menu for them instead of them just being under 'Tools', thus it would have its own section). As for the keys, I think giving them variable names just makes the code more readable overall. For example, someone coming into this might see "RtcYear", "RtcMonth", etc. scattered a couple dozen times in this wrapper and have no idea what's going on, but when I see things like YEAR_KEY, I understand intuitively what's happening (for example, "from the settings interface, get the integer value at this section and key and then write it into a value"). I imagine compiler optimizations completely smooth this over performance-wise, so I'm okay with the tradeoff of verbosity versus readability (as someone who currently thinks the codebase is already a bit impenetrable in places and who was only able to make this PR because the rest of SettingWidgetBinder.h self-documents so nicely). If, however, you think the compiler isn't clevering this conversion out of the code, I can set it to a char *, since I think the self-documentation is still really valuable.

[GovanifY]

The compiler is probably clever-ing it out, but it adds some burden to the human reading said code ("wait, is this cast done at runtime? wait no it's defined above").

Regardless, don't see the need for it but won't die on this hill either.