No longer require MODULE_EXPORTS and fix related issues

[marktsuchida]

MMDevice (in ModuleInterface.h) conditionally defined MODULE_API based on whether MODULE_EXPORTS was defined. The intent was (presumably) that device adapters would define MODULE_EXPORTS and therefore expose the module interface functions such as InitializeModuleData() (defined by the device adapter) and GetNumberOfDevices() (defined in ModuleInterface.cpp), whereas MODULE_EXPORTS would not be defined when building MMCore so that those functions are not included.

In practice, there were a few issues:

• In the Visual Studio build, we use the same MMDevice static library for both MMCore and device adapters. This static library was built with MODULE_EXPORTS, so the device module interface functions were being included in MMCoreJ_wrap.dll (this is harmless).
• When MODULE_EXPORTS was not defined, MODULE_API was incorrectly defined to __declspec(dllimport), which is irrelevant when libraries are loaded via LoadLibrary(). This also meant that ModuleInterface.cpp did not compile on Windows without MODULE_EXPORTS defined.
• In the Autotools build, MODULE_EXPORTS was never defined in any case (and had no effect either). The module interface functions were being included in libMMCoreJ_wrap (again, harmless).
• The macro name MODULE_EXPORTS is too generic.
• It would make more sense to make the device adapter case the default, and only define a macro when building MMCore.

So this PR replaces MODULE_EXPORTS with another macro, MMDEVICE_CLIENT_BUILD, with roughly the opposite meaning. Device adapters no longer need to define any macro, whereas building MMCore should define MMDEVICE_CLIENT_BUILD.

In addition, MODULE_API is now defined for GCC/Clang to explicitly give the functions default visibility, so that we can use -fvisibility=hidden when building device adapters in the future (doing so has a number of advantages but is not urgent).

To work around the way our Visual Studio and Autotools builds work (i.e., the common MMDevice static library), it is still possible to build MMCore using an MMDevice static library built without MMDEVICE_CLIENT_BUILD, as long as MMDEVICE_CLIENT_BUILD is defined when including the MMDevice headers during the MMCore build. This is similar to how MODULE_EXPORTS was previously being used on Windows. MMCoreJ_wrap will expose unnecessary symbols, but this is the same as the previous situation.

Note that device adapters (including any that are outside of this repo) do not need to change: defining MODULE_EXPORTS now has no effect but also does not do any harm.

It would be nice to also rename MODULE_API to something like MMDEVICE_API, but that would require changing the source code of all device adapters; probably not worth the disruption at this time. I did make it so that MODULE_API is not defined when MMDEVICE_CLIENT_BUILD is defined.

Finally, none of this affects the device interface version.

---

Manual testing

• Builds on Windows/vcxproj
  • DemoCamera exports CreateDevice
• Builds on macOS/Autotools
  • DemoCamera exposes CreateDevice
• Builds on Linux/Autotools
  • DemoCamera exposes CreateDevice
• pymmcore (setuptools) passes import test (with MMDEVICE_CLIENT_BUILD added)
  • Upgrade MMDevice/MMCore and fix macro defs pymmcore#111