Use memfs under the hood

[heygrady]

Related: webpack/webpack-dev-middleware#366

This PR is an attempt to re-imagine memory-fs as a bridge to memfs. I have simply extended Volume and added compatibility methods like normalize that the legacy memory-fs had. This should serve as a drop-in replacement for the old memory-fs with no interruptions. As far as I can tell this works just like the old memory-fs but with full fs api support.

All of the tests pass except the ones related to win32 paths. It appears that memfs has support for win32 paths but I don't yet know how to write tests against it.

streamich/memfs#327 (comment)

Why?

There are a number of issues here and around the web where people are trying to do novel things with memory-fs but it doesn't support their use-case. I personally ran into an issue when trying to use fs-monkey to require modules directly from a memory-fs volume. Sadly, memory-fs doesn't support the full fs api so some things aren't possible.

I'm not the only one. There are a number of people who have tried to make memory-fs do things it wasn't designed for. Many of those people end up finding memfs (streamich/memfs#323).

memfs has full fs API support and it is actively maintained. It is compatible with two very interesting packages: unionfs and fs-monkey.

Switching the guts of memory-fs to memfs while maintaining full API compliance with the old memory-fs seems like the best way to bridge the gap. The aim is to allow people to keep using webpack as they always did while enabling full fs api compatibility.

Does it work?

It should. We need to figure out how to test the windows paths and determine if people are doing weird things like trying to jam windows paths in memory-fs while on a posix machine (memfs tries to "do what fs would do" and that means following the path-type of the underlying system).