Resolve "Implement complex RPC arguments for ADM_register_job(), ADM_update_job() and ADM_remove_job()"

This MR implements the transmission of the complex RPC arguments required for the RPCs `ADM_register_job`, `ADM_update_job`, and `ADM_remove_job`.

It also makes the following deep changes to the source code:

1. The library core no longer uses C types for those RPCs. Also, C++ types 
   for those RPCs follow the [pimpl](https://en.cppreference.com/w/cpp/language/pimpl) 
   idiom to hide implementation details from the public API.
2. Refactors admire types by moving them to a dedicated 'admire_types' CMake target
   This makes it much simpler to share type definitions between the library
   and the daemons. Code structure is affected as follows:
    
   - C++ types are now declared in admire_types.hpp
   - C & C++ types are defined in types.cpp. The reason for them being in
     the same file is that the C type-creation functions use logging
     facilities that are C++ code. Until we offer a C interface for them,
     C-type functions need to be compiled with a C++ compiler.
3. Adds specific types to enable converting between RPC and API types
    
    This commit adds two generic templated types (managed_rpc_type<T> and
    unmanaged_rpc_type<T>) that simplify the lifetime management of any C-types
    created by Margo RPCs. They also offer conversion functions that allow
    converting between C RPC types and C++ API types.
    
    Both types internally create and store pointers to the C-structures required
    (or produced) by the RPC engine, but differ in how they manage these
    structures:
    
    - The `managed_rpc_type<T>` template internally manages the lifetime of the
      C underlying object and ensures that its destruction function will be
      called when the destructor for `managed_rpc_type<T>` is called.
    
    - The `unmanaged_rpc_type<T>` template only creates the C underlying
      object, but does not destroy it. This is useful when conversions
      are needed but the underlying data will be automatically destroyed by Margo.
    
    Specific conversions are implemented as template specializations. For
    example, `template <> struct admire::managed_rpc_type<admire::job>`
    allows converting from an `admire::job` instance to a newly-created `ADM_job_t`
    via its `get()` function. On the other hand,
    `template <> struct admire::managed_rpc_type<ADM_job_t>` allows converting
    from an existing `ADM_job_t` to an `admire::job` instance, also via its
    `get()` function.

Closes #25

See merge request !16

This commit adds two generic templated types (managed_rpc_type<T> and
unmanaged_rpc_type<T>) that simplify the lifetime management of any C-types
created by Margo RPCs. They also offer conversion functions that allow
converting between C RPC types and C++ API types.

Both types internally create and store pointers to the C-structures required
(or produced) by the RPC engine, but differ in how they manage these
structures:

- The `managed_rpc_type<T>` template internally manages the lifetime of the
  C underlying object and ensures that its destruction function will be
  called when the destructor for `managed_rpc_type<T>` is called.

- The `unmanaged_rpc_type<T>` template only creates the C underlying
  object, but does not destroy it. This is useful when conversions
  are needed but the underlying data will be automatically destroyed by Margo.

Specific conversions are implemented as template specializations. For
example, `template <> struct admire::managed_rpc_type<admire::job>`
allows converting from an `admire::job` instance to a newly-created `ADM_job_t`
via its `get()` function. On the other hand,
`template <> struct admire::managed_rpc_type<ADM_job_t>` allows converting
from an existing `ADM_job_t` to an `admire::job` instance, also via its
`get()` function.

This makes it much simpler to share type definitions between the library
and the daemons.

- C++ types are now declared in admire_types.hpp
- C & C++ types are defined in types.cpp. The reason for them being in
  the same file is that the C type-creation functions use logging
  facilities that are C++ code. Until we offer a C interface for them,
  C-type functions need to be compiled with a C++ compiler.

Resolve "File_options downloads not found"

Closes #33

See merge request !24

Resolve "Add Address Sanitizer configuration profile for CMake"

Closes #31

See merge request !22

Resolve "Invalid C-string in `examples/c/ADM_register_job.c`"

Closes #30

See merge request !21

Resolve "Integrate redis-plus-plus in build system"

Closes #16

See merge request !18

Resolve "Hide implementation of API types behind opaque types"

This MR implements creation and destruction functions for most library types the fields of which should not be directly accessed by clients.

It also moves the type definitions to their own `types.h` header.

Closes #26

See merge request !17