The intial benchmark results are not impressive.  Writing a bunch of
size_t values doesn't appear to be significantly faster than encoding
uint64 values in big-endian. And, when optmized to eliminate allocations
big-endian byte slices have consistently better performance
characteristics.

It doesn't seem like a good idea to expose the String function because
there may be a StringValue implementation of Value in the future.  So
this type either needs to be implemented premptively as a stub or
omitted for the time being.

This will provide better grouping of topics in godoc.  Uint stuff will
all be together and Uintptr stuff will all be together.

The byte-related Value stuff won't really be together, but that is a
tragedy of evolution.  Maybe for lmdb-go 2.0 this part of the Value and
FixedPage interfaces can be made consistent for all data types.

Instead using a method named Put, the name Append is used to more
closely match what it is doing.  This also more transparently exposes
slice appending semantics and its quirks (which were already there).

There is some additional overhead processing integer Multi variants but
I couldn't trust users if I were to make the types raw byte slices.

Using the word Value so much was really confusing because LMDB is a
key-value store and the word "value" already has a reserved meaning.

This is where the Data interface is defined as well as the generic
BytesData type.  This is also where the FixedPage interface is defined
because it seems like the most appropriate place, though the generic
Multi type has been left if val.go, mostly for historical reasons.  It
may be moved later.

It's not really clear how those functions should behave and the data
conversion functions provided should provide more help overall.

The are faster.

The convention in go is to differentiate functions based on their type
using a name suffix.  The previous names did not meet this convention
and it inconsistent where other functions in the package would follow
convention.

It turns out I have been using the official terminology backwards.  LMDB
associates keys with data.  Keys and data are both values (this was
a bit of a facepalm given the type names).

Fixes #103

This will effectively deprecate Cursor.PutMulti once merged.  It can
survive for a while longer.  But PutMultiple is a bit simpler if
somewhat slower.  The overhead of interfaces should be dominated by the
actual work of inserting items into the database in practice.

I am still working back from a spot where there were way too many
panics.  A new type, Stride, has been introduced with a method
Stride.Multiple which has the same signature as MultipleCUint and
MultipleCSizet.

These methods can be useful occasionally.  Examples were added to
demonstrate when slice syntax can be used instead.

Also, this change renames the receiver in CUintValue and CSizetValue
methods to be u and z resectively.  This will help drive the naming
convention that the Value* convertion functions adopted.