COMMON: Add numeric limits

[elasota]

There are multiple engines using their own min/max definitions because Common doesn't define them. In some cases they might even be buggy (i.e. wintermute.h defines UINT_MAX_VALUE as a signed constant so it's actually -1?)

This adds them to Common.

[lephilousophe]

Thanks for this addition which will bring us an architecture agnostic interface for limits.
There is some small changes though to make it cleaner.

[lephilousophe]

These constants should not be here.
Either private or not here at all to not expose them.
If we mimic C++11 STL, only functions are to be used.

[elasota]

OK, I'll move those into something else... but I do think these values need to be exposed in a way that doesn't need to call a function. It's not just numeric_limits equivalent that's missing, it's also things like INT_MAX and such... so while the functions will work for a lot of cases, they won't work for cases that either need a numeric constant (e.g. template args) or where using a function call would violate code standards by having an on-init function call.

[lephilousophe]

Maybe you can try constexpr?

[lephilousophe]

INT_MAX and so are really a different thing: they are macros handled by the preprocessor and can be used in #if directives.

[criezy]

Is there a good reason for not using std::numeric_limits directly?

I know our portability guide says that "the standard C++ library is a big no-no", and while I understand why we want to avoid things like std::string or std::vector, I think we could allow some flexibility here. For example we already use std::initializer_list<T> in common code.

[sev-]

I think we can safely use std::numeric_limits

[carlo-bramini]

Excuse me, why not simply using the definitions provided for the stdint types?
If the library supports std::numeric_limits, then I cannot see a good reason why the old good C99 macros shouldn't be also available.