Design: client library API

Nobody has claimed this yet.

Currently, all client library functionality is designed around direct interception of existing I/O APIs (either via linker wrapping or GOTCHA). As a result, there really isn't a defined client library API other than `unifycr_mount` and `unifycr_unmount`. This leads to quite a bit of redundant code, and doesn't adequately support alternate uses, such as
* direct application clients, like Hyogi's command line tools effort (#148)
* VeloC memory-based API
* memory-based object stores and shared/anonymous mmap regions (related to #248)

This issue is to track the code reorganization needed within the client library to cleanly abstract the UnifyCR functionality from the upper-level uses. Ideally, we would end up with a `libunifycr` that could be used directly by an application, or as a support library for by `libunifycr-posix` (and perhaps `libunifycr-mem`). My suggestion is that the `libunifycr` API needs a thoughtful design to support the various use cases, and should not be tied to POSIX APIs/semantics. The `libunifycr` implementation would contain all of the code to interact with the local `unifycrd` (i.e., RPCs and shmem communication, shared data types and any associated serialization).

Start with the existing unifycr_mount and unifycr_unmount entry points, then map how libunifycr, libunifycr-posix, and the client-side communication with unifycrd are organized. Review the related uses in #148 and #248. Done means a defined, non-POSIX-specific libunifycr API that can support direct applications and higher-level libraries while containing the RPC, shared-memory, data-type, and serialization logic.

Written by the indexing model from the issue text.