This function is a constructor, so let's name it like one and leave
_create() for the reference functions, which do create/write the
reference.

Path validation may be influenced by `core.protectHFS` and
`core.protectNTFS` configuration settings, thus treebuilders
can take a repository to influence their configuration.

An obvious place to fill the tree cache is on write-tree, as we're
guaranteed to be able to fill in the whole tree cache.

The way this commit does this is not the most efficient, as we read the
root tree from the odb instead of filling in the cache as we go along,
but it fills the cache such that successive operations (and persisting
the index to disk) will be able to take advantage of the cache, and it
reuses the code we already have for filling the cache.

Filling in the cache as we create the trees would require some
reallocation of the children vector, which is currently not possible
with out pool implementation. A different data structure would likely
allow us to perform this operation at a later date.

Keeping the cache around after read-tree is only one part of the
optimisation opportunities. In order to share the cache between program
instances, we need to write the TREE extension to the index.

Do so, taking the opportunity to rename 'entries' to 'entry_count' to
match the name given in the format description. The included test is
rather trivial, but works as a sanity check.

As reported by coverity, we would leak some memory in error conditions.

We can simply ask the hasmap.

If the user wants to keep a copy for themselves, they should make a
copy. It adds unnecessary complexity to make sure the returned entries
are valid until the builder is cleared.

Finding a filename in a vector means we need to resort it every time we
want to read from it, which includes every time we want to write to it
as well, as we want to find duplicate keys.

A hash-map fits what we want to do much more accurately, as we do not
care about sorting, but just the particular filename.

We still keep removed entries around, as the interface let you assume
they were going to be around until the treebuilder is cleared or freed,
but in this case that involves an append to a vector in the filter case,
which can now fail.

The only time we care about sorting is when we write out the tree, so
let's make that the only time we do any sorting.

By inserting in the right position, we can keep the vector sorted,
making entry insertion almost twice as fast.