Make play nice with FilePaths

[oxinabox]

Without this PR glob mostly works on FilePathsBase.jl types at least for local PosixPaths.
but it returns results that are Strings.

By allowing the type for the matches arrays to be determined based on the type of the inputs,
we can fix that.

This will break when/if rofinn/FilePathsBase.jl#15 comes though.
But til then at least this works.

cc @rofinn

[coveralls]

Coverage decreased (-12.8%) to 79.851% when pulling 2164581 on oxinabox:ox/FilePathsFriendly into ed18d97 on vtjnash:master.

[coveralls]

Coverage decreased (-12.8%) to 79.851% when pulling 2164581 on oxinabox:ox/FilePathsFriendly into ed18d97 on vtjnash:master.

[rofinn]

1. Why would Drop AbstractString subtyping rofinn/FilePathsBase.jl#15 break this? Isn't matching the input and output types a good idea regardless of whether the filepaths need to define a specialized method?
2. We could also include a specialized method in https://github.com/rofinn/FilePaths.jl along with the URI stuff.

[oxinabox]

Why would rofinn/FilePathsBase.jl#15 break this? Isn't matching the input and output types a good idea regardless of whether the filepaths need to define a specialized method?

It wouldn't break this PR,
but it would cause Glob.jl to stop working with FilePaths again (regardless of this PR),
since it has type-constraints on a bunch of path (prefix) arguments requiring them to be subtypes of AbstractString.
This PR does not relax all those type-constraints to Any.
(and I've not yet checked if that is possible.)

[oxinabox]

@vtjnash bump

[vtjnash]

Yes, I need to revisit this, now that rofinn/FilePathsBase.jl#15 is merged, and add tests for this. It has just been too low on my priority list for years.

I would like someday to write a package FakeFilesystem, which implements the FilePathsBase AbstractPath API, but only operates in-memory, and can be used as a test-only backend to test this package. Hopefully someday.