Use submodules to handle dependencies | Fix your library!

In #52, I found that I needed to install third-party sources in order to get the build working. However, I don't like the method of having to download sources manually. I strongly encourage moving to [git submodules](https://git-scm.com/docs/git-submodule) to manage these dependencies. This would simplify the dependency fetching process immensely: simply run `git clone https://github.com/adobe/XMP-Toolkit-SDK.git --recurse-submodules`, and presto, dependencies are downloaded! In addition, running `git submodule update` would keep dependencies up-to-date.

Furthermore, there is really no excuse to not do so, since both manually-fetched dependencies are available through git: [zlib](https://github.com/madler/zlib) (or [zlib-ng](https://github.com/zlib-ng/zlib-ng), for that matter) and [libexpat](https://github.com/libexpat/libexpat).

** RANT ALERT **

If I am coming across as a bit harsh, I apologize, but this library is really not fun to work with. Most libraries I encounter have simple buildsystems (e.g. `mkdir build; cd build; cmake ..; cmake --build .`) that rely on system-bundled dependencies where possible (e.g. use CMake's `find_package`). In contrast, this library uses a strange conglomeration of make and CMake, requires manual download and placement of third-party dependency sources, and then, when I try to build (using `make` for simplicity instead of trying to wrap my head around a lot of different targets), fails with a linker error about not being able to locate `libssp.a`. Sure, a failure to find a library isn't that terrible, but I can't turn up a lot of information online. After `grep`ping through the build directory, I found something terrifying.

**Somebody [hardcoded](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/build/ProductConfig.cmake#L124) the path to compiler libs on Linux without bothering to verify that (a) the GCC dir is going to exist at `/user/unicore/i80386linux_x64/compiler` (it doesn't; probably no modern Linux distro even has `/user`), (b) the user has GCC 4.8.2 (they won't, given the fact that GCC is all the way to [11.2](https://gcc.gnu.org/gcc-11/)), (c) the user is using Linux kernel 3.10 (I sincerely hope they are not), (d) the user is on a 64-bit platform (most users are, but a few might be running code on legacy machines), or (e) the user is even using GCC (some people do use clang at times, myself among them).**

Given all this, my level of enthusiasm for using this library is very low. Why use a library that is going to be a pain to work with?

** END RANT **

Sorry to disturb you with this rant. Have a nice day! 🙃

Start with build/ProductConfig.cmake around line 124, then inspect the existing make and CMake build paths and how zlib and libexpat sources are fetched. Compare the current dependency setup with Git submodules and verify that a recursive clone or submodule update makes the documented build process work without hardcoded compiler-library paths.

Written by the indexing model from the issue text.