Memoize the zipfile namelist when it's safe to do so.

[benjyw]

If the zipfile is in 'r' mode, we know it can't change under
us, so it's safe to lazily memoize the namelist (augmented with
the implied directories).

We propagate the memo to all Path objects created from
some existing Path object, for maximum effect.

We memoize the namelist as a set, to make lookups into it efficient.
This brings into focus the fact that iterdir's iteration order is arbitrary.

This was actually true before - the order we were getting in
practice was "all the explicit names, in zipfile insertion order,
followed by all the implicit dirs, in zipfile insertion order of
the descendants from which we inferred them). This isn't a
particularly intuitive or useful order for end users. However
pathlib's iterdir, which this one emulates, also does not guarantee
anything about order (it appears to in practice on MacOS, but not
on Linux). So it seems proper to double-down on this lack of order.

To allow for ordering when needed, this change adds ordering semantics
for Path objects, to make it easy to sort them if you need to.
The tests now use this sorting.

As a result of this change, in 'r' mode, exists() and joinpath()
are constant time instead of linear time. They are still linear
in other modes.

Existing tests have been extended to also run on on-disk zipfiles opened
in 'r' mode, and a new test has been added, to verify the performance fix.

[jaraco]

I feel pretty good about this change. I have some ideas about how to tweak it a bit, but that doesn't have to block adoption. Having the unit test to prevent regression is really great, so thank you for that.

[jaraco]

Please have a look at #34, where I've taken inspiration from this contribution and refactored it into a design I'm much more comfortable accepting.