Slices: added Big-Endian versions of method to read and write fixed-size 16, 32 and 64 integers, and helpers to create slices filled with a specific byte pattern

- Ex: WriteFixed16(...) will use Little-Endian (does not sort lexicographically) while WriteFixed16BE(...) will use Big-Endian (does sort lexicographically).
- Slice.Repeat(count, byte) creates a slice filled with a specific byte.
- Added SliceHelpers.SetBytes that uses memset() when possible.
Performance: don't mark private or public Slice fields as readonly, to reduce the number of copies on the stack

- See Jon Skeet's blog about this issue: http://msmvps.com/blogs/jon_skeet/archive/2014/07/16/micro-optimization-the-surprising-inefficiency-of-readonly-fields.aspx
- tl;dr: any readonly struct is first copied on the stack when you invoke a method or property on it (enven if it is immutable)
- readonly Slice are everywhere and called a lot, especially in the SliceReaders and Subspaces :(
- Made all 'public readonly Slice' into a private backing field
- added '//PERF: readonly struct' comment marking, until there is a better way to mark these fields somehow.
Updated unit test to reflect the fact that a memory leak was fixed in fdb_c v2.0.8

- native memory is now properly cleared when tr.Reset() is called
Fixed yet again a mixup between big and little endian !!!

- Most of the Slice.ReadIntXX() and ReadIntXXBE() were reversed.
- Tuple parsing code was also calling the wrong method, which itself was doing the reverse, so the bug wasn't discovered until now.
Fixed typos in comments
Early prototype of a command line shell for FoundationDB with everything that is missing from fdbcli

- moved over the cd, dir, tree, sampling, and other commands
- added auto-completion on directory names for cd command
- uses Mono.Options for parsing command line args
- uses Miguel de Icaza's getline.cs for a nice shell with history and autocompletion
Fdb.System.EstimateCountAsync() can take an IProgress<T> to report progress when counting very large ranges
Test Commit, Please Ignore

- This is a totally legit commit, there is nothing particular about it.
- This is not the commit you are looking for. Please move along.
</COMMIT>
- Added cheaty way to bypass the InvalidOpEx you get when getting the Key of a Directory Partition
FDBShell: refactored and added more commands

- version, status, show, topology, shards, ...
- sampling now works on the current directory
- more to come!
FDBShell: now comes with even less build breakage!
Added FdbKeyRange.All that returns range [00, FF)
FDBShell: added 'map' commands that helps find where stuff is
FDBShell: a bit of cleanup

- "cd" with nor args will display infos on the current directory
- "map" will show the largest directory it found
FDBShell: tweaked sampling to show separate distributions of keys and values (+median)
Bored Now: added XML comments
Micro optimisation: optimized Buffer<T>.ToList() for small, single-page results

- Most short range queries, like FirstOrDefault() or SingleOrDefault() only have a single result that can be added quickly without needing a tmp array
System: reduced the max window size of Fdb.System.EstimateCountAsync

- When counting in subspace with very large values, a window size of 65536 need to traverse a LOT of data (multiple Gigs)
- Smaller initial window size to help count in almost empty subspaces that are right before a huge subspace with very large keys
- This is still not ideal. Counting ranges with large keys and/or values is currently sub-optimal and may trigger a lot of future_version errors
Compressed Bitmap Indexes: [Work in Progress] very rough first prototype of compressed bitmaps encoding and decoding

- Uses a variant of Word Aligned Hybrid coding with 32 bits words and 31bits literals.
- Supports APPEND, SET, CLEAR, AND, OR and XOR on compressed bitmaps without needing to uncompress them
- Compressed words are in stored in little endian (host order) to simplify things a lot.
- Don't use this yet, it's still full of bugs !
Fixed test regression: KeyComparer of an index merge expression can be null
Changed the wording of the comments on Fdb.OpenAsync to discourage people from calling it every time they need to access the database

- Fdb.OpenAsync may be confused with SqlConnection.Open() (which you do on each transaction, and uses a pool underneath)
- The original name in the C API is fdb_database_create which may also be confused with something else...