estreams revised

* Egon Spengler was right, crossing the streams is bad.
* Restored both src/gpgme.def and src/libgpgme.vers to use the
  estreams symbols without the leading underscore.
* The new_from_estream() function added to lang/python/src/core.py and
  set to alias the new_from_stream() function remains.
* Opted for the solution favouring Linux onthree main grounds:
  1. Andre reported major problems with Windows as well, so the number
     of potentially affected systems would vastly increase.
  2. All the BSDs and OS X have spent far more time and development
     work in order to accommodate the eccentricities of both Microsoft
     and the GNU Project (ref. GCC), so they're more likely to be able
     to cope with doing so again than the other way around.
  3. If I really have to I can write a custom installer for OS X to
     try this and, if it fails, to then patch the two symbol entries and
     recompile from scratch.  That said, I may not have to since it
     actually behaved during the most recent tests for this
     commit; into ten separate CPython installations and all five
     supported versions (standard source installs and OS X Framework
     installs for each version).

Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>

src/gpgme.def

@@ -273,7 +273,6 @@ EXPORTS
     gpgme_op_encrypt_sign_ext_start       @203
 
     gpgme_data_new_from_estream           @204
-    _gpgme_data_new_from_estream          @205
 
 ; END
 

src/libgpgme.vers

@@ -135,7 +135,6 @@ GPGME_1.1 {
     gpgme_op_decrypt_ext_start;
 
     gpgme_data_new_from_estream;
-    _gpgme_data_new_from_estream;
 
 };