brisbane: initial cut at a mergeline cache

[Ian Clatworthy]

Robert Collins wrote:

> Don't update on read operations, its not safe, and unlike dirstate there
> is no need to do so as only write-locked operations can change the state
> it would cache.

I don't think that's an option. The whole basis for the design is *not*
to impact write operations in any way, just save some key data calculated
during the first read operation, making subsequent ones are faster. Without
this approach, it will *never* be scalable for the very reasons you needed
to abandon the old cache you mentioned.

And we need *some* answer, if not the mergeline cache. It simply isn't
realistic to tell projects like OOo that

  bzr log/st/diff -rN

takes a few seconds as long as N isn't off the mainline ('cause then
it will take a few minutes).

Ian C.