apps: POC for bitfield-based compile-time apps

[FintasticMan]

Proof-of-concept for using the value of the Apps enumerations for a 64-bit bitfield for choosing what apps to include at compile-time. The reason for making this is because we want to minimise the number of places people need to add their new app to. By using the values of the Apps enumerations and a bitfield developers don't need to add their app to another place just for it to be togglable at compile-time. (Inspired by https://github.com/InfiniTimeOrg/InfiniTime/pull/1408#issuecomment-1455078843).

This also attempts to use the preprocessor as little as possible, and I've got it down to one ifdef for the declaration of disabledApps.

For some reason, this increases flash usage considerably, but it does fluctuate as expected by changing the disabledApps variable.

The implementation for the ApplicationList is really ugly (and clang-format can't format it properly), so if anyone has any suggestions on how to make that nicer, it would be much appreciated. It also doesn't move apps in the UI, so there are just gaps wherever apps have been disabled.

Another issue is that, to disable apps via the CMake command-line, users need to calculate bitwise operations for the apps they want to disable. This isn't very friendly, so if someone has any ideas, I'd love to hear them.

Fixes #1114

[github-actions[bot]]

Build size and comparison to main:	Section	Size	Difference
text	407564B	864B
data	940B	0B
bss	53632B	64B

[FintasticMan]

Now the ApplicationList is a little bit cleaner, but it still leave holes in the app list UI where the apps used to be.

[minacode]

Nice to see someone else play around with this concept, too! 😊

I will take a closer look at your idea with the bit array.

In #1408 I aimed to fix the holes in the application list by creating the array iteratively in a function and hoping for the compiler to optimize it 😄

[FintasticMan]

This isn't the way we want to solve this issue.