Consider performance implications of repeatedly-layered FS

Opening this issue to track the discussion and not have it be closed when #79 is merged.

@CvvT in https://github.com/MSRSSP/litebox/pull/79#discussion_r2045474294:

For other dev files, are we going to implement one fs for each dev file and chain them together through layered fs? Would that be slow?

@jaybosamiya-ms in https://github.com/MSRSSP/litebox/pull/79#discussion_r2045587100

Important questions to answer I think: whether we actually need other dev files (the only ones that come to mind are random,urandom,null,full,zero---those could be considered one/two file systems, depending on how we want to split it), and what the actual cost of the indirection through the layered system really is.

There is a real cost indeed to things that are "lower" in a deep layered system, but in terms of what the actual impact of that is, I don't think it should be particularly significant for most applications. If it is, there are ways we can flatten the tree, and speed things up (e.g., by having "advertisements" of supported files, which the layered FS can cache and directly forward through with a single hash lookup instead); we could also merge the various device files together if even that is a bottleneck.

But yeah, generally speaking, I am not too worried about the performance for this (at least at the moment), especially given that most "bottleneck" files are likely to end up in in-mem layer, which is guaranteed to be the top layer.

Your question is 100% valid though, and we should think about what alternative designs give us the nice separation, while also reducing the impact on performance.

Start with the linked discussion in pull request #79, since no source file or test is named here. Identify the layered filesystem implementation and a representative way to measure lookup or access cost. Done means the project has evidence about repeated layering and a recorded decision on whether to flatten, cache, or merge device files.