Do not use exceptions control flow

[HarryR]

trafficstars

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

This fixes the problems described by:

• https://github.com/gstew5/snarkl/issues/11
• https://github.com/gstew5/snarkl/issues/12
• https://github.com/ConsenSys/zero-knowledge-proofs/issues/13
• https://github.com/CodaProtocol/coda/pull/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 https://github.com/CodaProtocol/coda/pull/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.