Enable LTO and more optimizations for release builds

The program's binary is more than 1,5 MiB in size (after stripping debug
symbols). Although in general that is not a size to worry about, keeping
a small binary and memory footprint is beneficial in the majority of
cases and leaves a tangentially better impression with users.
To that end, this change enables the following optimizations to be
performed when creating a release build:
1) We compile with optimization for code size. We have no performance
   sensitive code and are communicating with a slow I/O device to begin
   with, meaning that binary size will ultimately have the most weight
   when judging the program. Hence, minimizing it seems like the best
   trade-off.
2) We enable link-time optimization (LTO). At the expense of compilation
   time (which is not a concern for what may almost be considered a
   one-off operation), this step can reduce binary size by eliminating
   more unused code as well as enable performance related optimizations
   not possible without this setting. For similar reasons we disable
   incremental builds and treat the entire compilation as one unit.

The end result of these optimizations is a reduction of binary size by
almost a fourth (420 KiB).
Those optimizations come at little to no cost (depending on one's view).
There is another one that we could enable and that is to abort on panics
instead of unwinding, yielding savings of 44 KiB. However, we refrained
from doing so because that has a negative impact on the amount of error
reporting happening in case of a panic.

0 files changed, 0 insertions, 0 deletions