Merge #1295: abi: Use dllexport for mingw builds

bc7c8db abi: Use dllexport for mingw builds (Cory Fields)

Pull request description:

  Addresses the first part of #1181. See the discussion there for more context and history.

  After this, all that remains is a (platform-independent) exports checker for c-i. Or perhaps a linker script or .def file could be tricked into testing as a side-effect.

  This should fix mingw exports, specifically hiding the following:
  `secp256k1_pre_g_128`
  `secp256k1_pre_g`
  `secp256k1_ecmult_gen_prec_table`

  This changes our visibility macros to look more like [gcc's recommendation](https://gcc.gnu.org/wiki/Visibility#How_to_use_the_new_C.2B-.2B-_visibility_support).

  Edit:
  Note that we could further complicate this by supporting `__attribute__ ((dllexport))` as well, though I didn't bother as I'm not sure what compiler combo would accept that but not the bare dllexport syntax.

  Edit2:
  As the title implies, this affects this ABI and could affect downstream libs/apps in unintended ways (though it's hard to imagine any real downside). Though because it's win32 only, I'm imagining very little real-world impact at all.

ACKs for top commit:
  hebasto:
    re-ACK bc7c8db, only a comment has been adjusted since my recent [review](#1295 (review)),
  real-or-random:
    utACK bc7c8db

Tree-SHA512: 378e15556da49494f551bdf4f7b41304db9d03a435f21fcc947c9520aa43e3c655cfe216fba57a5179a871c975c806460eef7c33b105f2726e1de0937ff2444e

include/secp256k1.h

@@ -133,8 +133,9 @@ typedef int (*secp256k1_nonce_function)(
 # define SECP256K1_NO_BUILD
 #endif
 
-/* Symbol visibility. See libtool manual, section "Windows DLLs". */
-#if defined(_WIN32) && !defined(__GNUC__)
+/* Symbol visibility. See https://gcc.gnu.org/wiki/Visibility */
+/* DLL_EXPORT is defined internally for shared builds */
+#if defined(_WIN32)
 # ifdef SECP256K1_BUILD
 #  ifdef DLL_EXPORT
 #   define SECP256K1_API            __declspec (dllexport)