Decide: should respect-ignore take a policy the way respect-gitignore does?

## Context

#447 gave `.gitignore` a three-valued policy — `never`, `repository-only` (the
default) and `always` — and left `respect-ignore` a boolean. That puts the two
kinds of ignore file on different terms:

| | read when |
|---|---|
| `.gitignore` | per `respect-gitignore`: never, inside a repository, or always |
| `.ignore` | whenever `respect-ignore` is on, from every parent directory, with or without a repository |

`.ignore` is therefore effectively `always` and cannot be anything else. A tree
with an `.ignore` two directories above it has that file applied whatever
`respect-gitignore` says, and there is no way to ask for the `repository-only`
treatment of it.

This is the `ignore` crate's own arrangement: `Ignore::matched_ignore` consults
`.ignore` without the `saw_git` gate that bounds `.gitignore`, and `parents` is
one flag for both kinds.

## Observed behaviour

```console
$ printf '!kept.md\n' > outer/.ignore
$ printf '#Hello.' > outer/proj/kept.md
$ cd outer/proj && mado check .
```

`outer/.ignore` applies, with or without `proj/.git`, and under every value of
`respect-gitignore`.

## The decision to make

**Should `respect-ignore` take the same three values?**

- *Leave it a boolean:* `.ignore` is mado's and ripgrep's convention rather than
Git's, and it has no repository to be bounded by in the first place. Its
ancestors applying is the behaviour ripgrep users expect.
- *Give it the same policy:* the two settings would read alike, and a user who
wants nothing from outside the tree could ask for it. `repository-only` would
have to mean something for a file Git knows nothing about, which is the
awkward part; `parents` being one flag for both kinds means mado cannot bound
one without bounding the other.

## Related

- #346
- #447