Find a more efficient way to distribute the official ZWO SDK

[bgottula]

Right now this repository contains multiple versions of the official ZWO SDK, and new ones are added from time to time. Each one of these directories is 40-80 MB in size, which means that the entire repository already uses about 500 MB of disk space with just five versions. I'm not super happy with this situation and it will only get worse as new versions are added.

Some potential alternatives:

• Remove the SDK from this repository, and then do one of the following:
  • Users are expected to obtain the SDK themselves, either by downloading it from ZWO's website or by install it using the libasicamera2 package on Ubuntu systems.
  • Put the SDKs in a separate Git repository. This doesn't seem much better than the current situation, since if I decide to clone this separate repo I'd still have to store all versions of the SDK on disk even if I just want one.
  • Perhaps we could store individual SDK versions in some cloud storage service. This wouldn't be that much better or different from downloading directly from ZWO's website except that we can make older versions available. (ZWO only makes the most recent version available for download.)
    • CMake provides some support for downloading stuff via FetchContent, though I'm not sure if it really makes sense to automate that (after all CMake doesn't install required system packages automatically).
    • GitHub's Releases feature might be a useful way to distribute things.
• Use Git LFS to store these files. This adds a tiny bit of friction on first usage since LFS support is not typically installed/enabled by default on the client side. It's also really meant to store individual files that are large, rather than a large directory containing many smaller files, so I'm not sure if it's really a good fit. GitHub does support LFS.
• Keep only the most recent SDK version at the head of master and use some form of shallow cloning to avoid storing all the prior versions on disk. This is not ideal because shallow cloning in Git isn't well supported, and there may be legitimate reasons to use an older version of the SDK with our own code at the head of master. Stuff that's buried in the commit history is effectively inaccessible.

@jgottula interested in your thoughts.