Github Action workflow changes to run examples (#2)

[nalinigans]

• Fixes for sscanf_s/localtime_s/fopen_s issues Workaround for mainly Microsoft Visual Studio C API. Some Linux C runtimes do support this - see https://en.cppreference.com/w/c/io/fscanf and even if supported it says we need to define STDC_WANT_LIB_EXT1 before #include which makes the usage hacky.
• Run CI on all branches for push and PRs
• Get examples running in Github Actions for a sanity check.
• Pass _Debug flags for gcc/clang compilers for Debug builds

Note: The builds pass for Windows/Linux, but fail on MacOS because of Issue #116. Not sure if using regex is OK, but please see https://github.com/nalinigans/muparserx/blob/46d69f91cc15a3b3d52556d560a348ce79721117/parser/mpValReader.cpp#L70 for a possible fix to Issue #116.

[beltoforion]

As for the fix. The double value reader should not create complex numbers that just feels wrong. The regex may make this quite slow too. For me it feels like if this is how the solution looks like i'd rather keep the problem. Not sure what to do about this one yet.

[nalinigans]

Agreed that performance will be an issue with regex.

The double value reader should not create complex numbers that just feels wrong

I am probably missing something, are we not doing just that here?

btw experimented using std::atof instead of regular expressions and it seems to work. Would that be a possible solution? See here.

[beltoforion]

Ouch... I forgot about that. In my defense I wrote this code probably more than 6 years ago. However past me was already awesome so I redact my statement from two days ago and would now like to state that there is nothing wrong with this function returning a complex number. My best guess is I never liked it but figured it is a necessary evil because any alternative would be way more difficult.

I may have found something better than atof to fix #116. It seems to work. I have updated the archive accordingly.