Initial sqldiff commit.

The two csv files a short examples for experimenting.
They are sourced from the same dataset, but randomized so they only have partial
overlap and so they are *out of order*
I've arranged, also, that they share two blocks of identical rows near the starts.
Import my SQLdiff paper scrap notes
Checkpoint: first functional table diffing algorithm.

Slow, verbose, and the API isn't full there, and it only detects
changes as adds or deletes, not updates, but it runs.
Useful sqlite script
Describe the algorithm I used; import thoughts on plugging into the larger system.
stub out tests
Added some basic tests, which found critical bugs; wrote a simpler impl to shake them out.
Wrote applydiff() and made the simpler diff() impl pass its tests.
Stumbled onto an entire spec for a table diff output format.
Update Home.md
checkpoint. just some todos, really.
dataprotocols
Merge branch 'master' of github.com:majdal/modex into databased
Functional prototype of diffu: diff with updates.

Now, a reminder that normal diff *only* deals in updates and deletes
(but through a side effect of its design, is good about lining up the pairs which represent changes)
but the [COOPY spec](http://dataprotocols.org/tabular-diff-format/) has provisions for it
and in the context of tables with lots of columns it makes of sense.

This algorithm is inspired by that observation of regular diff:
it first runs the diff algorithm from last night to get {add,delete}s
and the reprocesses the results, looking to see if it can compress
pairs (delete, add) into a single (update,).
I would love to bang this down into a single algorithm which only does a single sweep
As is, it certainly is expensive; it makes the whole runtime something like p*(n + n^2)
(however, compared to [diffkit](https://code.google.com/p/diffkit/source/browse/trunk/src/org/diffkit/diff/engine/DKRowDiff.java) I suspect this is reasonable)
Requisite thanks
For practice, a generalized merge which can operate on any number of iterables.

This is useful because the first approach to sqldiff sorts the tables and then
scans them with an algorithm that looks an awful,
and applying a diff looks an awful lot like)

If this code took cmp and key functions and then we were polymorphically clever,
it could even be directly used to generate human readable diffs,
by calling merge(cleverness1(L), cleverness2(deletions), cleverness3(additions), ...)
since a readable diff is a list of lines, some of which are not prefixed (the unchanged set)
some of which have +s (the additions), and some of which are prefixed by -s
and in the first approach we spec'd that inputs and outputs are always sorted lists.

I love it when things work the first time I write them.
(okay, to be fair, I haven't tested the generalization part,
but the code works on 2 arrays and it's totally symmetric about which
arrays its working on, so I'm pretty confident)
Support reversed= on merge(), like sorted() does.
Support key= as well.

Now mergesort() matches the API of sorted()
More importantly, merge can now be exploited for clever hacks.
drop(), which is going to come in handy in a moment.
humanized_diff(); only works on V1, so switched back to that.

This elegantly uses merge() with the fact diff()-V1 heavily relies
on sorting to print out the table interleaved with the changes.
Next: use this to experiment; I have this theory that every update
corresponds to an adjacent add/delete, and this will give intuition.

This commit also includes a bunch of scrap code which is work
towards generalized diffu() (using linear programming!)
NOT TO BE USED, but I also don't want to lose it right now,
so it's going into source control.