Bad performance with the initial serving from fat jars, or when caching is disabled

### Issue

When serving a web app where some resources are from a large jar, we have noticed that the initial serving takes a long time, especially on Windows. And it takes much longer, for every refresh, if `-Dvertxweb.environment=development` is set which disables the vertx caching.

### Version

4.3.3

### Context

We have been using vert.x (web) for serving our web app and recently I've decided to get to the bottom of some performance issues we have been noticing for a while. We are not serving that many resources (72 requests, total transfer of around 2MB), but a large portion of the resources are coming from a **big jar**. The issue is that:

- in production (caching enabled properly), the **initial serving** of the web app is slow
- and in development, every refresh takes very long because we have set -Dvertxweb.environment=development which disables the vert.x caching.
- Opening Chrome Devtools will make things much worse because chrome automatically request sourcemap files, some of which we don't have. So **requesting non-existing resources takes particularly lon**.
- the **bigger** the jar, the **slower** it gets
- The issue is especially severe when server is **running on Windows** - the refresh of the landing page could take minutes.

It primarily causes pain for development. With caching turned on the developers will have to restart the process when resources are changed, and take the performance hit of "initial serving". But if caching is turned off, every refresh is slow so it is even worse dev experience.

### Some Investigation

I did look into the source code, and some digging it appears to me that the issue comes from `FileResolverImpl::resolveFile`. It "recursively" unpacks the entire jar which is extremely slow when the jar is large and when running on Windows (I am not too sure about what is particular about Windows but I tried on three different boxes and get the same behavior).

I do understand that the recursive unpacking is to support directory listing properly (https://github.com/eclipse-vertx/vert.x/issues/2126), but should it:

- either check if directory listing is enabled and skip the unpacking, or
- check if caching is enabled and skip the unpacking?

After all, the unpacking is just to hydrate cache but there is no cache (or no directory listing) in this case so the unpacking seems to merely create unnecessary load?

Alternatively, is there any way to disable caching only for the files served from local folder, but enable caching from jar resources?