ssp: prioritize stack guard init constructor

Other libraries might also be running constructors, which themselves are built with SSP enabled,
or are calling functions that are.
If those then get ordered befor the ssp constructor, they might crash due to the yet to be initialized
__stack_chk_guard.

This at least affects a statically linked glib, which launches a background thread in the
libgio constructor.
If the ssp constructor then runs at a random point after, it initializes the stack guard, and once
the thread returns from whatever function it's in, it crashes because the stack guard changed.

Signed-off-by: Timo Rothenpieler <timo.rothenpieler@uni-bremen.de>