Was there a reason why modules_mapping was originally a repository rule rather than a rule rule?

@kormide In the early days, the modules mapping was considerably faster compared to depending on all the wheels from pip_install. It was important because we were generating it on the fly (not checked-in as part of the gazelle manifest like we do now). This is not true anymore.

I was working on this a bit earlier since the previous version didn't work with --find-links and thought it could make sense to generate a modules_mapping.json for each wheel individually. I've refactored what I had to work with this rule and drafted a change that runs the generator once per wheel then merges the result. It seems to address the issue of having to recompute the module mapping for all dependencies each time one is updated.

Not really sure of a good way to benchmark it beyond rough timings and checking for cached actions, but it seems like it should be more efficient. Could also combine the json merger with the yaml generator if having them separate adds too much overhead, but I wasn't sure if there was another use for the merged json file beyond making the yaml one. I pushed the changes here.

@corypaik - interesting approach. We have been using it on a large project and haven't felt the need to do this performance improvement since the testing to check whether the checked-in manifest is up to date or not doesn't require recomputing the whole file.

The most expensive part of updating the modules mapping is downloading and, in some cases, compiling native modules. The tree traversal to generate the mappings is usually super fast and I don't think the performance improvement would be noticeable?

I think making this a simple rule also fixed #574 because the same fetch packages can be now used here. So thanks for this change!