Do not use exceptions control flow

[HarryR]

This pull request removes the usage of try ... catch for control flow in the get_evaluation_domain function.

This fixes the problems described by:

• Is this library expected to work against libsnark master? gstew5/snarkl#11
• Update to work with libsnark:master gstew5/snarkl#12
• Run-time errors on OSX Consensys/zero-knowledge-proofs#13
• Libsnark get_evaluation_domain works on macOS MinaProtocol/mina#1419 (notable, this made them fork the project & include in their repo instead of a git submodule).

When exception control flow is disabled at the compiler-level, either by choice (to generally speed things up) or by requirement (e.g. the Cheerp WASM compiler doesn't support catching exceptions), then the code either abort() or picks the wrong option. This was also triggering misbehaviour with optimised builds on OSX with Clang (where the wrong option is picked, due to buggy catch handling).

This commit also comments-out the comment in the inline-assembly in basic_radix2_domain_aux.tcc, which was breaking Emscripten WASM builds due to it lacking support for inline assembly (of any kind).

There is a different patch in MinaProtocol/mina#1419 but it breaks compatibility with the API, this patch remains API compatibility.

I added the get_root_of_unity_will_throw function, to determine if getting the root of unity will throw, however I need to avoid duplicating the code at:

• https://github.com/scipr-lab/libfqfft/compare/master...Ethsnarks:no-exceptional-control-flow?expand=1#diff-7f675b64d35bdeb1d7103625e9b88e69R32
• https://github.com/scipr-lab/libfqfft/compare/master...Ethsnarks:no-exceptional-control-flow?expand=1#diff-532af60399ad53afa0e3ec23dc6cb717R27

I will make these changes to be included in the pull request.

[HarryR]

I feel there may be a cleaner way of doing this, I am open to suggestions.