A very common operation we want to do throughout our codebases is go from a Module to an Image. However, you can't - the question would be, why not?

The answer is that we have an intermediate state, a ModuleFileSet, that "flattens" a Module from what amounts to a set of .proto files and a lock file, to a set of combined .proto files that represent both the module's .proto files and the dependencies' .proto files. This is what we pass to i.e. protocompile. Currently, to compile a Module, you first need to make a ModuleFileSet, and then pass the ModuleFileSet to the bufimagebuild.Builder.

This can make some kind of sense in the abstract, but in practice, 99.9% of our usage of bufimagebuild.Image is someone creating a ModuleFileSetBuilder right before, creating a ModuleFileSet, and then creating an Image. This is wasteful and confusing to those who don't fully understand the (convoluted) type system in bufmodule - you should be able to go right from a Module to an Image.

On top of this, confusingly, ModuleFileSet inherits from Module, which causes a host of issues. There are places in the code where one might be expecting a Module, but are instead passed a ModuleFileSet, which stealthily modifies the behavior of GetModuleFile such that files from both the sources and dependencies will be returned. You could, in fact, also create a ModuleFileSet from a ModuleFileSet, recursive behavior that our code does not actually handle (and will result in a bug from duplicate files).

It's been a longstanding TODO in the codebase to eliminate ModuleFileSet altogether, and instead just use Modules, perhaps with a function on Module AllFiles() that returns what amounts to a ModuleFileBucket, a type that will be completely distinct from Module.

This PR does the first step of this: it changes bufimagebuild.Builder to take a Module instead of a ModuleFileSet, and then just inlines the (very) simple operation that ModuleFileSet does. To do this, bufimagebuild.Builder now takes a ModuleReader directly. In practice, in our codebase, this eliminates a lot of extra code to use a ModuleFileSet, and makes it easier for future developers to understand how to do from Modules to Images.

One thing that is a little more complicated with this is some unit testing we do around modules and their dependencies - often, you want to pass a manually-built ModuleFileSet to the bufimagebuild.Builder. To help with this, new functions have been added to bufmoduletesting with examples to provide functionality to build test lock files and test ModuleReaders.

One pain point is buf export, which actually needs both the equivalent of ModuleFileSets, and the ability to build an Image, but this is minor and can be dealt with when ModuleFileSets are actually eliminated. However, for now during this migration, bufimagebuild.Builder handles the case if a Module is actually a ModuleFileSet, and does not call the ModuleFileSetBuilder in this case.

A PR in core will be done in conjunction with this PR to handle the new behavior.

This PR also reverts the addition of NewReadWriteBucketWithOptions in storagemem, which isn't consistent with the rest of our codebase.