Memory churn in jimage code affects startup after resource encapsulation changes

After 9+148 a number of startup and footprint benchmarks show significant, sometimes large regressions.

Analysis shows this is due to the changes to resource encapsulation, which means that when calling ClassLoader::getResource with a resource name that's not encapsulated we will now scan every module for resources. What this means is that ImageReader code that was previously seldom seen during startup is exercised more often than not.

Experimenting with the code that shows up in profiles has proven that by reducing memory churn in some places we can recuperate a significant portion (>50%) of the regression, showing that most of the measured footprint overheads comes from increased allocation and touching of memory pages early on in an application's lifecycle.