Refactor and streamline copy_files handling

[Andrew-S-Rosen]

Closes #1742.

Note:

• Dictionaries and tuples with AppFutures do not get implicitly resolved Parsl/parsl#3108

Motivation

In short, the copy_files handling was in desperate need of a behind-the-scenes overhaul. There are several reasons for this.

1. As noted in Copy file passing breaks in dispatched workflows  #1742, you can't do Path() on a Future, which means any recipes doing Path() (or string concatenation of paths) in a Flow are going to crash when dispatched over a workflow engine.
2. There are several file handling functions that do redundant things or are handled in existing dependencies: copy_decompress_files, copy_decompress_tree, copy_decompress_files_from_dir.
3. Because of Point 2, not all the functions handle things in the same way. For instance, only some have glob support right now, which is confusing.
4. There are many instances where the type hints are simply inaccurate. For instance, in the Espresso recipes, the prev_dir: str | Path positional argument is often getting dict entries thrown into, as a result of pw_copy_files and such (see the test suite).

Because of this mess, things were in desperate need of a revamp, which this PR addresses.

User-Facing Changes

In most cases, there are no breaking changes to users and is mostly an internal refactor. Some positional arguments of prev_dir have been renamed copy_files for consistency with the type hint, although no user changes are expected if used as positional. Some internal functions have slightly modified behavior, such as copy_decompress_files. Refer to the function signature for more.

[Andrew-S-Rosen]

Thanks, @Nekkrad! Much appreciated. I'll likely go ahead and merge this in the evening here so that it can unblock a few other PRs (including one of yours). I'll make any changes to your PR to ensure everything passes after I do --- no need for you to do anything there. In any case, I wanted to communicate this minor but notable change in terms of how files are handled.

[tomdemeyere]

Haven't had time to look at this in details (I am off this week). I think your last sentence summarise very well my first thoughts about this:

Users have full flexibility now, and everything is internally consistent.

Which is very positive

[Andrew-S-Rosen]

@tomdemeyere No worries. Try not to open GitHub too much on your time off. 😉

Much of this refactoring was due to nice feature additions you made, so thank you! I will go ahead and merge this shortly, but when you return, don't hesitate to reach out if there are any issues/concerns.

[Andrew-S-Rosen]

Alright, this sucked up half a week of my life but in the end, there should be no major breaking changes (while also resolving #1742). There are some gnarly Future-resolving things for me to solve with Parsl, but that's for later and shouldn't impact current recipes. Refer to the PR summary for details.