Evaluate stack guard implementation(s)

Right now we have at least three ways to ensure stack-smash does not happen.
- CONT guard check, with two u32 at both start and the end our struct. Additionally, we implement stack size check and fill our local array with the same value. ref. https://gitter.im/esp8266/Arduino?at=630eddaff4d7a323dead0fcf and https://github.com/esp8266/Arduino/blob/master/cores/esp8266/cont_util.cpp `cont_...` functions related to checks and 're-painting'
- `-fstack-protector` that instruments functions (also [`__attribute__((stack_protect))`](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes) to manually inject such checks) with guard variables and a special `__stack_chk_{guard,fail()}`; ref. https://gcc.gnu.org/onlinedocs/gccint/Stack-Smashing-Protection.html and https://github.com/esp8266/Arduino/blob/master/cores/esp8266/core_esp8266_postmortem.cpp implementations
- StackThunk also implements guards for its stack through a similar mechanisms (ref. `stack_thunk_fatal_overflow()` and main implementation in https://github.com/esp8266/Arduino/blob/master/cores/esp8266/StackThunk.h)

Could GCC implementation supplement both StackThunk and CONT? Or, replace it? (see `__attribute__` above)
Should CONT checks randomize its guard value to separate stack contents themselves from structure guard members?
Could we add something like [address sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm) that verifies that we don't go over the stack boundaries, not just protect us from writing things *over* one specific u32 value?
w