Provide way to disable rebuilding features on admin/modules page

I'm experiencing this problem as well. On our Drupal Commons site, Features executes a shocking 3,757 queries. After commenting out the features_rebuild() line, it drops to 332. Admittedly, we probably have other issues here with features_rebuild() requiring so many queries, but combined with the general overhead of the modules page (parsing all the .info files), rebuilding features on the modules page puts our server over the top.

As a work-around, we're currently disabling Features' hook_form_alter() with this:

/**
 * Implements hook_module_implements_alter().
 */
function site_helper_module_implements_alter(&$implementations, $hook) {
  // TODO: Hack until https://drupal.org/node/2036935 is fixed.
  // Remove the features_rebuild() call on the modules page.
  if ($hook === 'form_system_modules_alter') {
    if (array_key_exists('features', $implementations)) {
      unset($implementations['features']);
    }
  }
}

I'm adding a patch with implementation similar to the one for rebuilding features when flushing the cache.

That features_form_system_modules_alter hook is so specific it makes me wonder what the original purpose for doing this was. I looked at the code and this line comes from the original commit of Features was back in 2009. So there isn't any comment or issue to tell us why this was needed.

Maybe it goes back to something in D6 or older Features that isn't needed anymore.

Unlike the Flush case, I'm tempted to make the default value be False instead of True so that it doesn't rebuild on the Module page. I honestly wasn't even aware it was doing that and it explains why the module page is so slow sometimes.

Since I just did the 2.8 release I'm not going to rush out another release for this so we have time to discuss it. Interested in others opinions, especially if anybody can think of a reason why this rebuild on the modules page is even necessary.

From what I know about software development and first commits, I would guess there never was a reason for the hook.

Scenario one:
Developer knows he needs to rebuild features in some situations, but is unsure when, so he takes a guess and doesn't validate the guess.

Scenario two:
Developer is resolving an actual problem, tries a couple of things, one of them works, he gets distracted with something else, both changes stay.

Here is a version that defaults to FALSE.

Committed to 430d3ca.