Merge #793: Make scalar/field choice depend on C-detected __int128 availability

79f1f7a4f123765cf07be92ae894d882c5845191 Autodetect __int128 availability on the C side (Pieter Wuille)
0d7727f95e52d99c13f55c64e9d1f799ba7d7967 Add SECP256K1_FE_STORAGE_CONST_GET to 5x52 field (Pieter Wuille)

Pull request description:

  This PR does two things:
  * It removes the ability to select the 5x52 field with a 8x32 scalar, or the 10x26 field with a 4x64 scalar. It's both 128-bit wide versions, or neither.
  * The choice is made automatically by the C code, unless overridden by a USE_FORCE_WIDEMUL_INT{64,128} define (which is available through `configure` with a hidden option --with-test-override-wide-multiplication={auto,int64,int128}).

  This reduces the reliance on autoconf for this performance-critical configuration option, and also reduces the number of different combinations to test.

  This removes one theoretically useful combination: if you had x86_64 asm but no __int128 support in your compiler, it was possible to use the 64-bit field before but the 32-bit scalar. I think this doesn't matter as all compilers/systems that support (our)  x86_64 asm also support __int128. Furthermore, #767 will break this.

  As an unexpected side effect, this also means the `gen_context` static precomputation tool will now use __int128 based implementations when available (which required an addition to the 5x52 field; see first commit).

ACKs for top commit:
  real-or-random:
    ACK 79f1f7a4f123765cf07be92ae894d882c5845191 diff looks good and tests pass
  elichai:
    tACK  79f1f7a4f123765cf07be92ae894d882c5845191

Tree-SHA512: 4171732668e5c9cae5230e3a43dd6df195567e1232b89c12c5db429986b6519bb4d77334cb0bac8ce13a00a24dfffdff69b46c89b4d59bc6d297a996ea4efd3d