THRIFT-5898: Replace global variable with a singleton getter

[CJCombrink]

Replace the global GlobalOutput variable with a static method call to get a singleton instance, preventing the need to export the symbol.

This issue also blocks conan from adding 0.22.0 (see conan-io/conan-center-index#27382)

• Did you create an Apache Jira ticket? THRIFT-5898
• If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
• Did you squash your changes to a single commit? (not required, but preferred)
• Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
  • This is a breaking change for users of the C++ library that uses the GlobalOutput variable
• If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

[uilianries]

@CJCombrink I just wanted to thank you for taking care of that issue!

[CJCombrink]

I see the AppVeyor build now fails for something else:

TNonblockingSSLServerTest.obj : error LNK2019: unresolved external symbol "private: static bool apache::thrift::transport::TSSLSocketFactory::manualOpenSSLInitialization_" (?manualOpenSSLInitialization_@TSSLSocketFactory@transport@thrift@apache@@0_NA) referenced in function "public: __cdecl GlobalFixtureSSL::GlobalFixtureSSL(void)" (??0GlobalFixtureSSL@@QEAA@XZ) 

I will need to look into this as well

[CJCombrink]

Applied the comment from here: #1714 (comment)
to the TSSLSocketFactory to remove the need for the exported member

[emmenlau]

Overall a good change.

[emmenlau]

Could this be in a separate PR, to add shared library build? This PR here is 99% only about replacing GlobalOutput, which is useful to me independent of shared libraries.

[CJCombrink]

It is actually related: In #3229 I disabled building the shared libraries due to this PR still outstanding with the mention there that I would put it back, see b1e7cfb

Also building a shared library was broken and this is (my) the proposed solution to said problem.

[CJCombrink]

To follow up on mail conversation:
The CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS does not export global symbols according to the cmake docs

However, there are some cases when compiling code in a consumer may require explicit dllimport markup:

• Global data symbols must be explicitly marked with __declspec(dllimport) in order to link to data in the .dll.