Taking into account the hierarchy of inputs

- [x] I have read through the manual page (`man fzf`)
- [x] I have the latest version of fzf
- [x] I have searched through the existing issues

## Info

- OS
- [x] Linux
- [ ] Mac OS X
- [ ] Windows
- [ ] Etc.
- Shell
- [ ] bash
- [x] zsh
- [ ] fish

## Problem / Steps to reproduce

Many thanks for this excellent tool! After using it for a while and searching the existing issues, I would like to point out a possible direction in which the matching of fzf could be improved.

Like many people, I often use fzf to filter lists of file/directory names. For example, there could be the following directories

```
projects/foo
projects/foo/doc
projects/foo/src
projects/foo/tests
notes/some/category/foo
```

When fzf is launched with the above list of choices and the user searches for “foo”, the results will be presented in the above order, i.e. the three subdirectories of `projects/foo` will be considered more relevant than the notes on "foo". However, it could be argued that for a hierarchy of directories and files the subdirectories of `projects/foo` are already covered by the match of their parent. After all, they do not provide any further reason to match.

In the above example with only five items there is no problem, but with thousands of matching items it is easy to miss top-level matches that are shown behind subitems of other top-level matches.

Is there a way to solve this issue by configuration of current fzf? If not, perhaps we could discuss here possible solutions?

Start by checking fzf's current matching and ranking behavior and whether existing configuration can express hierarchy-aware results. Done would require an agreed solution that prioritizes top-level matches over their nested paths, with behavior confirmed using the directory examples in the issue.

Written by the indexing model from the issue text.