Core functionality ok; workable kernel

There are now individual lillyput_BindRequest() and such calls, each with their LillyPack_BindRequest* and similar types that make parameters reachable under ASN.1 field names. These are implemented as static inline calls that directly call lillyput_operation() with an opcode and with parameters cast to (dercursor *).

This makes LillyDAP a usable kernel. Still to be desired before 1.0 are:

• unpacking of parameters insideSEQUENCE OF and SET OF
• Have an API to work with LDAP Controls
• Splitting the LillyDAP structure into per-connection and generic components

First workable version

LillyDAP can now be used to receive and send data. Receiving goes all the way down to callbacks, sending starts at the level of LDAPMessage.

We added a (seemingly mature) CMakeLists.txt with support for

• CMake with options for BUILD_SINGLE_THREADED and USER_SUPPLIED_PATCHLEVEL
• CTest although we don't currently match stdout yet, just the exit() code
• CPack has been tested with the generators DEB, RPM, NSIS — which seem to work

The versioning scheme for ARPA2 reserve only major/minor numbers for the software release process, with additional RCn, alphaN or betaN versions that may be overruled by the packager. This is the use of USER_SUPPLIED_PATCHLEVEL which refers to the Git patchlevel by default, including progress since the last tagged version. You must not have local changes to the source code if you want to use this.

Early release, readonly LDAP to operation functions

This is an early release of LillyDAP, with only the capability of reading and parsing LDAPMessages; writing is addressed later. The lock-free concurrency model for the output queue has however been established.