Reproduced by introducing UtilityProcess gtest, failing TestDllBlocklist.NoOpEntryPoint, because of UtilityProcess sandbox' call to GetPrespawnCigExceptionModules()

Firefox.exe has its own function table of Kernel32's functions so that we can
use them before the executable's import table is resolved. The table is in
the shared secion, where the launcher process puts the offsets of the functions
and the browser process resolves them to the function addresses.

The problem is when the browser process calls GetDependentModulePaths to get
the list of dependent modules that is also in the shared section, it remapped
the write-copy view to get the list visible in the mapped view. As a side-effect
of this remapping, the function addresses are gone and the browser process cannot
use the RedirectToNoOpEntryPoint blocking technique. This is not a problem in
the production environment, but it caused GTest failures.

After I examined the events carefully as below, it turns out that this remapping
is not really needed because GetDependentModulePaths is used when we launch
a child process with pre-spawn CIG, which is long after all the dependent modules
are loaded.

1. Browser process gets a writeble handle via the shared section
2. Add dependent modules to the writable view (before the process's entrypoint)
3. firefox!wmain calls ConvertToReadOnly() to convert the writable handle to
   a readonly handle
4. The first module loading maps a write-copy view, which contains a complete
   list of the dependent modules
5. Or, the first call to GetDependentModulePaths() maps a write-copy view
   (No need to remap the view here)

When the browser process calls GetDependentModulePaths, the list of the dependent
modules are complete and there is no needed to remap it.

The proposed fix is to remove the line remapping the section.

https://hg.mozilla.org/mozilla-central/rev/775c224cfaa9