Compile modules into shared libraries.

[ta0kira]

This should improve compile times overall, and will likely be necessary for larger programs. For example, even PrimesDemo currently requires 64 .o and .a files when linking.

---

It should be easy to just link all of the object files and direct dependencies into a single .so per module.

• Binaries should initially still default to static linking, with a new .zeolite-module option to do dynamic linking.
• Tests should probably use dynamic linking, just to cut down on execution times.

[ta0kira]

This needs to be done in a way that avoids accidentally linking in the same .o or .a into a target more than once. For that matter, linking in .as should probably be avoided overall: I'm not sure if the entire .a will be included in the .so, or if it'll just link in what's required by the .os. (I think base is currently the only module that uses .as, which all modules will directly depend on. I don't even remember why I started using .as in the first place.)

Another issue is with the naming of the .sos. I don't think the names need to be unique, since initially I don't want to use -rpath, or otherwise allow relocation of the .sos. They can just live in .zeolite-cache (primarily so that recompilation deletes the previous version) and share a common name like module.so.

Also, there needs to be a clear way to handle empty modules. Is there a situation where linking of one module would attempt to link to an empty module? Even though an empty module can have public_deps, category deps would be resolved to the owning module rather than the empty module. So, it should be fine to skip the .so if a module has no compiled files.

---

Using shared libraries should also make #173 obsolete, at least for binaries that use dynamic linking.

For linking preferences, there might also need to be a distinction between "static" (just static linking of Zeolite code) and "standalone", which could mean avoiding dynamically linking to C/C++ libraries.