Support for more methods, new error API, unit test in libhexagonrpc

[flamingradian]

This supersedes #6 (at least if the design makes sense).

Method definitions

The largest change is to the method definitions. The new top-level struct is hrpc_method_def_interp4. It contains an array of inner types, and of accepted arguments which may reference inner types by array index.

An argument is defined as a tuple of 2 numbers: type and data. Currently, data is either a size or an index for an inner type. Referencing open source IDL's on the internet, this is the conversion:

in uint32_t: 0 4
in uint64_t: 0 8
in struct: 1 (TYPE SIZE)
in struct with a sequence: 2 (TYPE ID)
in sequence<type>: 3 (TYPE SIZE)
in sequence<struct with a sequence>: 4 (TYPE ID)
rout type: 6 (TYPE SIZE)
rout struct with a sequence: 7 (TYPE ID)
rout sequence<type>: 8 (TYPE SIZE)
rout sequence<struct with a sequence>: 9 (TYPE ID)

Inner types are basically arrays of arguments, used to define a type that has a sequence as a member. They are restricted to 2 of the types, currently preventing recursion:

type: 1 (TYPE SIZE)
sequence<type>: 3 (TYPE SIZE)

Interface files

With the addition of inner types, it's harder to keep the array defined in a macro that can change based on compilation unit. The only readable option I found was to split the data structures into a C file, while the inline functions go in the header file.

The inline functions are changed to pass the file descriptor and handle from thread-local variables instead of parameters. This is similar to how the original fastrpc does it, but it still requires explicit hexagonrpc_fd_from_env(void) and hrpc_open_...(size_t n_err, char *err) calls at the start of the program.

More information will be provided as this gets developed. There are a lot of changes to the API, so it will take some work to get this ready.

[flamingradian]

In libhexagonrpc, the use of function pointers brings up a performance concern since the CPU might not be able to pipeline effectively. GCC inlines things to the point where the functions are known at compile-time, while Clang doesn't inline emit_args unless __attribute__((always_inline)) is specified or -Ofast is passed.

This optimization can be compiler-specific for now. First, we need to decide on one implementation. Since no other issues have been raised here, I'll let this supersede #6.

[flamingradian]

The __thread variables make the project less readable, especially without much documentation. It should just be deferred.