No apparent way to use async APIs in route/service guards

## Expected Behavior

I should have a way to create route/service guards which use functions like `tokio::fs::canonicalize` in a guard.

## Current Behavior

I have to reimplement part of the router in a single default route to work around the inappropriateness of using `std::fs::canonicalize` in an async server, which currently has me going down a rabbit hole of how extractors are implemented and what `FromRequest` code to copy into my own functions while trying to make some code into a reusable framework to share between several projects so I don't have to make an unmaintainable mess of `macro_rules!` and `$foo::tt` to do it.

## Possible Solution

**Option 1 (more generally applicable):** Add `Scope::guard_async` and `Route::guard_async`

**Option 2 (potentially a rabbit hole of "more extension points here too, please"):** Since I'm basically bypassing and re-implementing `actix_files::FilesService` to customize the directory listings and add programmatic whitelisting to the file-serving route, add a method to override the directory-rendering function and add support for async guards on the file-serving portion of `actix_files::FilesService`.

## Steps to Reproduce (for bugs)

1. Read the docs and notice the type signature on `Scope::guard` and `Route::guard` lacks an `async` and there are no apparent async counterparts.

## Context

I'm implementing various tools that are variations on the `actix_files::FilesService` concept, but going beyond what it's capable of in three ways (so far), and I'm trying to deduplicate the code between them... and trying not to make an unmaintainable mess of `macro_rules!` in the process:

1. Custom directory listings

* A "like miniserve, but an image gallery" tool with a grid of thumbnails that are generated and stored in the XDG [Thumbnail Managing Standard](https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html) cache on-demand using a thread pool connected to the actix-web executor via an async-able channel for a job queue and `tokio::sync::oneshot` to make thumbnailing completion awaitable.
* A more traditional `mod_autoindex`-esque file server that themes its contents up to look like a MacOS Finder window or a Windows 9x Explorer window or a Windows 3.1x Program Manager (category lists) of File Manager (file lists) window or the like, for use on my airgapped retro-hobby LAN.

2. Whitelisting files allowed to be served (eg. the image gallery imposes permission restrictions on which directories may be listed and only allows certain file types to be served verbatim.)

3. Interspersing static and non-static files (eg. so the URLs in the address bar stay nice and clean, non-`mod_autoindex` routes go under `/_/` while `mod_autoindex` routes go directly in the site route. (i.e. `/_/base.css` served from rust-embed and `/served_file.png` served dynamically as a `actix_files::NamedFile`.)

In the future, I may also explore replacing some/all of the folder listings with something more dynamic (eg. When I get to DOS, I may want to mimic XTree Gold and generate/maintain a cache of a recursive traversal of the filesystem, or I may want to say, if `/foo/bar` contains a `.index.sqlite3`, then query that to build the listing instead of using file-listing so I don't have to maintain a forest of symlinks.), which is part of the reason I thought this would work better as async guards than extending `FilesService`.

## Your Environment

- Actix Web Version: `docs.rs/actix-web/latest`, which appears to be 4.2.1