A recent change to ansi-term [1] means that `ANSIString`s can now hold either
owned *or* borrowed data (Rust calls this the Cow type). This means that we
can delay formatting ANSIStrings into ANSI-control-code-formatted strings
until it's absolutely necessary. The process for doing this was:

1. Replace the `Cell` type with a `TextCell` type that holds a vector of
   `ANSIString` values instead of a formatted string. It still does the
   width tracking.

2. Rework the details module's `render` functions to emit values of this
   type.

3. Similarly, rework the functions that produce cells containing filenames
   to use a `File` value's `name` field, which is an owned `String` that
   can now be re-used.

4. Update the printing, formatting, and width-calculating code in the
   details and grid-details views to produce a table by adding vectors
   together instead of adding strings together, delaying the formatting as
   long as it can.

This results in fewer allocations (as fewer `String` values are produced), and
makes the API tidier (as fewer `String` values are being passed around without
having their contents specified).

This also paves the way to Windows support, or at least support for
non-ANSI terminals: by delaying the time until strings are formatted,
it'll now be easier to change *how* they are formatted.

Casualties include:

- Bump to ansi_term v0.7.1, which impls `PartialEq` and `Debug` on
  `ANSIString`.
- The grid_details and lines views now need to take a vector of files, rather
  than a borrowed slice, so the filename cells produced now own the filename
  strings that get taken from files.
- Fixed the signature of `File#link_target` to specify that the
  file produced refers to the same directory, rather than some phantom
  directory with the same lifetime as the file. (This was wrong from the
  start, but it broke nothing until now)

References:

[1]: ansi-term@f6a6579ba8174de1cae64d181ec04af32ba2a4f0