info: Allow using matching options in more situations

File matching options like --include will be rejected in situations where
there is no filename to match against. (Or where there is a filename but
it's not relative to the cwd, or otherwise seemed too bothersome to match
against.)

The addition of listKeys' was necessary to avoid using more memory in the
common case of "git-annex info". Adding a filterM would have caused the
list to buffer in memory and not stream. This is an ugly hack, but listKeys
had previously run Annex operations inside unafeInterleaveIO (for direct
mode). And matching against a matcher should hopefully not change any Annex
state.

This does allow for eg `git-annex info somefile --include=*.ext`
although why someone would want to do that I don't really know. But it
seems to make sense to allow it.
But, consider: `git-annex info ./somefile --include=somefile`
This does not match, so will not display info about somefile.
If the user really wants to, they can `--include=./somefile`.

Using matching options like --copies or --in=remote seems likely to be
slower than git-annex find with those options, because unlike such
commands, info does not have optimised streaming through the matcher.

Note that `git-annex info remote` is not the same as
`git-annex info --in remote`. The former shows info about all files in
the remote. The latter shows local keys that are also in that remote.
The output should make that clear, but this still seems like a point
where users could get confused.

Sponsored-by: Jochen Bartl on Patreon

doc/todo/info__58___allow_file_matching_options_for_all_keys.mdwn

@@ -9,3 +9,5 @@ git-annex: File matching options can only be used when getting info on a directo
 There should be a way to use `info` to query aggregate information properties of all keys instead of directories.
 
 I have used `git annex info .` in the repos I used up until now because every key was in the tree. Though I also have a feeling that operating on all keys could be significantly faster than filtering them to match some directory.
+
+> [[done]] --[[Joey]]

doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_1_3b96becda1db6ae23adb5077b6332718._comment

@@ -12,6 +12,8 @@ where used, but now `matchNeedsFileName` is available and it could only
 reject those.
 
 So this can be implemented by making cachedPresentData
-and cachedRemoteData get the matcher, check if it's
+and cachedRemoteData (etc) get the matcher, check if it's
 the right kind and apply it to the keys.
+
+done
 """]]