Add new display style so it cycles trough all existing styles

[BaltasarParreira]

Hi, this my change to add a new style to this fantastic and fun clock project, great work on the retro game animations.
So I thought it's a pity that with these amazing animations why we need to get stuck seeing only one at the time, so I create this so each 5m the display style changes to the next one and so on.
Like these we can enjoy all of them.
Hope you like it. ; )

To choose just in the web settings page select the new option (last one) and save.

The order I choose to show the styles is this:
1- Standard Clock
2- Mario Animation
3- Space Invaders
4- Large Clock
5- Arkanoide
6- Pac-Man Clock

[Keralots]

Before I can merge, there's a problem I need to flag: this PR accidentally removes the HTTP Control API that landed on main just before you branched (commit 7182993, which closed #49). The first commit ("Add display style Cycle All Styles") is +1 / −115 on src/web/web.cpp - the one added line is the new dropdown <option>, but the other 115 deleted lines are all of the /api/status, /api/display/on|off, /api/display/brightness, /api/mode/clock|auto, /api/clock/style, and /api/reboot handlers and their route registrations. The second commit similarly drops httpForceClock and the isDisplayForcedOff() guard in src/main.cpp.

This looks like an editor working from a copy of web.cpp / main.cpp from before that API was merged, so committing it reverted the feature even though your branch base was current. Could you rebase onto the latest main and re-apply just the cycle changes on top? The end result should be web.cpp with only the new <option value="7"> added and nothing removed.

Two small things on the feature itself, no rush:

• When switching styles, it'd be good to call the existing resetClockAnimationState() so each animation starts clean instead of inheriting the previous one's state.
• On the "Fix time drift" commit - the earlier tm_min / 5 block version with the firstTimeSynced guard was actually solid; the % 5 == 0 version can advance the screen immediately if the first NTP sync happens to land on a multiple of 5. Happy to keep either, just flagging it.

Once the API deletions are out, I'll pull it in. Thanks again for contributing!