I'm squeezing this in for similar reasons as #8. I wondered whether
these additions would be breaking. The short answer is no. In
addition, adding this now means `level-read-stream` can make use of
it without conditional code paths based on `db.supports.*`.

Ref Level/abstract-leveldown#380

Adds key and value iterators: `db.keys()` and `db.values()`. As
a replacement for levelup's `db.create{Key,Value}Stream()`. Example:

```
for await (const key of db.keys({ gte: 'a' }) {
  console.log(key)
}
```

Adds two new methods to all three types of iterators: `nextv()` for
getting many items (entries, keys or values) in one call and `all()`
for getting all (remaining) items. These methods have functional
but suboptimal defaults: `all()` falls back to repeatedly calling
`nextv()` and that in turn falls back to `next()`. Example:

```
const values = await db.values({ limit: 10 }).all()
```

Adds a lot of new code, with unfortunately some duplicate code
because I wanted to avoid mixins and other forms of complexity,
which means key and value iterators use classes that are separate
from preexisting iterators. For example, a method like `_seek()`
must now be implemented on three classes: `AbstractIterator`,
`AbstractKeyIterator` and `AbstractValueIterator`. This (small?)
problem extends to implementations and their subclasses, if they
choose to override key and value iterators to improve performance.

On the flip side, the new methods are supported across the board:
on sublevels, with encodings, with deferred open, and fully
functional. This may demonstrate one of the major benefits of
`abstract-level` over `abstract-leveldown` paired with `levelup`.

Yet todo:

- [ ] Tests
- [ ] Replace use of `level-concat-iterator` in existing tests
- [ ] After that, try another approach with a `mode` property on
      iterators, that is one of entries, keys or values (moving
      logic to if-branches... I already don't like it but it may
      result in cleaner logic downstream).