Remove _FORTIFY_SOURCE definitions

[gemesa]

Fixes #205

With this PR the _FORTIFY_SOURCE level will be left to be handled by the distros default from now on. The previous approach could potentially downgrade the _FORTIFY_SOURCE level, especially if the compiler was internally setting it (i.e., not via CPPFLAGS), leading to unintended security configurations.

[GoGoOtaku]

This is a bit of a head-scratcher for me on how to handle this. On one hand this is a minor security "hole" on the other hand no distro and certainly no compiler would ever set this higher than _FORTIFY_SOURCE=1.
At fortification levels 2 and 3 are similar to -O2 and -O3 in that they change code behavior. While _FORTIFY_SOURCE=1 is usually ok to do _FORTIFY_SOURCE=2 and _FORTIFY_SOURCE=3 can break code at runtime (afaik).
Now tbf this shouldn't happen if the code is well written but a lot of code just isn't and so I don't know if distros as a whole set this to a higher default value. I don't use Ubuntu but Gentoo and Arch did not throw such errors so my guess is that they don't have a default value or at least not a high one.

This rather old but still relevant blog post by redhat recommends it's use to developers.

[gemesa]

I see you merged this in the end. How did you arrive at this conclusion? Is there any additional information?

[GoGoOtaku]

I chose to check out how other, larger open source projects do it and the ones I looked at either don't bother with it at all (e.g. distcc, gcc) or only set it for tests (e.g. ConsoleKit).
As a test I compiled it with _FORTIFY_SOURCE=3 and it compiled and was usable. My guess here is that I will just put it up to maintainers to make sure they set stuff. Long term we are switching to cmake. My guess is that a lot of hardened versions of distros will enable this kind of check for everything anyway. If need be I might make a hardened flag in the long term after we switch to cmake.