✨[FEATURE REQUEST] LTO

[SizzinSeal]

Overview
Linker Time Optimization (LTO) performs optimizations during linking, as the name suggests. This allows for more aggressive optimizations, especially around binary size, and especially in larger projects with many files.

Is your feature request related to a problem? Please describe.
The PROS cold package is huge. This makes wireless upload times very long when updating the cold package, and downloading new kernel versions slower, a big problem with slow internet. It also makes online storage a concern.

OPTIONAL Describe any solutions you've considered
GCC has a -flto flag to enable linker-time optimization

Additional context
This requires modification of the common.mk file, it's not related to the PROS API.

[djava]

Um, does LTO work nicely with dynamic linking? I'm unsure if we would actually get any shrinkage of binary size - If anything, I would expect binary sizes to grow from this without that because the symbols are all visible by default (see: The cobs_encode clashing issue, #418), but would be additionally inlined more heavily causing more duplication.

That issue could probably be mitigated if we do quite a bit of littering [[gnu::visibility("hidden")]] (or the equivalent __attribute__((visibility("hidden"))) in C) around the kernel codebase for anything internal.

Experimentation would be needed to determine if this is worth doing, as well as evaluating the compile-time tradeoff.

Regardless, within each individual template you could turn on LTO, as the PROS template format allows additional Makefiles to be added. This might be good enough for what you want.

I could also see an argument that LTO could be turned on for user projects and not for the kernel, but I'm doubtful of any observable benefit there in the vast majority of cases.

Overall, I'm not against this but I don't think its a no-brainer without further investigation.