Add -fno-exceptions support

[Maeiky]

To be able to build without exceptions enabled. Required for Clang + Mingw with "-fno-exceptions" flag.

[nmcclatchey]

This PR is worthy of careful consideration, but is not quite ready for merging. Enabling the library's use even in the case of -fno-exceptions would enable even broader acceptance, provided that it does not break existing use cases. Some comments, on why I consider it unready, and how to bring it to a ready state:

• The mechanism you chose is GCC-only. Ideally, the library would not break if a user were to employ it in Visual Studio, Clang, etc. You can ensure this using appropriate preprocessor macro checks. To detect GCC, check whether the macro __GNUC__ is defined. You can then ensure that the standard throw is used for all other compilers.
• __throw_exception_again is not the right mechanism for throwing a new exception; consider __throw_<<exception_name_here>> instead. When -fno-exceptions is supplied, the code __throw_exception_again std::runtime_error("What?") will still construct an instance of std::runtime_error.
• Wherever a piece of code exists only to throw an exception, the entire piece should be disabled if -fno-exceptions is used. As an example:

  #ifndef NDEBUG
      if (mCounter.load(memory_order_relaxed) != kWriteBit)
          __throw_exception_again system_error(make_error_code(errc::operation_not_permitted));
  #endif

  is better formulated as:

  #if defined(NDEBUG) && defined(__cpp_exceptions)
      if (mCounter.load(memory_order_relaxed) != kWriteBit)
          throw system_error(make_error_code(errc::operation_not_permitted));
  #endif

  Note that __cpp_exceptions is one of the proposed C++20 feature-testing macros, so it is more portable than the GCC-only __EXCEPTIONS and __throw_* macros. To enable compatibility with the majority of C++11 compilers, however, will require more sophisticated approaches.

[Maeiky]

I changed all "thow" with _throw<>. I just need some verification for the corresponding functions.

[alxvasilev]

__throw_system_error is implementation-specific, which makes the code non-portable (and would break if the standard library changes its internals). As nmcclatchey said, ideally this library should be usable with all other popular compilers under Windows, not only gcc.

[Maeiky]

I add one file "mingw.throw.h" to be more flexible and to be easily implementation-specific. For now with this, without the "-fno-exceptions" flag, the throw system is untouched, so this will work on others compilers, as is it now.

[nmcclatchey]

Some notes about the new commits:

• Falls back to using exceptions if the compiler is not known to state whether it supports exceptions. (Currently, only GCC and Clang are known to do so, using __cpp_exceptions and compiler-specific macros)
• 788f81a is a general quality improvement, which should increase performance in the rare cases when it's used by reducing the total number of trips into the compiler's prefered exception-handling mechanism. That it improves support for -fno-exceptions is convenient, but a secondary concern.
• Because both try and catch require exception support (in GCC, at least), they have been removed if the library is being compiled without exception support.
• Macros with lower-case names (rather than the expected UPPER_CASE) have been replaced with functions; this improves encapsulation, reduces chance of usage errors, and removes errors related to macro argument types (eg. failed attempts to convert instances of error code enumerated types to int).

[BtbN]

Is there a reason this was reverted? I'm running into this very issue right now.