Dont rebuild any cache / menu / modules on verify, as those things cant change. ( ~30 times faster verify )

The only way modules could change or get removed is during a migration or a clone. It cant happen during a verify process, as the platform has not been rebuild and stays the same. Therefore it is not needed to :

- clear the cache
- rebuild the nodeaccess table
- the menu tree

And all those others in clear_6.

Iam pretty sure people will argue here, as i see a lot of people hacking arround the "migrate" step, by modifiying the platform on the master, which already has been deployed ( e.g. by git pull or directly ), and using verify for resync with the remote. Why i understand the workflow, its still a hack. We should really stick to what we have in aegir:
1. if you want change a platform, create a new platform in aegir on base of this ( or use the make file )
2. migrate the old site to the new platform

This ensures that we know, that only migrate / clone can actually "change" number / site / version of modules, thus they need this kind of "clear". If someone "imports", it is expected to have the same codebase. If someone changes those version by any reason, we should add a simple task "rebuild caches" in the UI, so people can trigger this manually.

This "clear" is a completly overkill for larger installations and cannot just be done for the sake people hack aegir for development.

Nevertheless i created this patch to still support the old behavior by default, but adding the ability to set "rebuild_cash=false", so it get skipped. I leave the "discussion" what the default should be look like to the devs, i have simply added this to my .drush/drupalwiki.drush.inc (call it the way you like it) to disable those rebuild for me by default. ( this can be used for the UI also )

function drush_drupalwiki_pre_provision_verify() {
  // never rebuild caches on verify of a site
  if (d()->type === 'site') {
    drush_set_option('rebuild_caches', FALSE);
  }
}

Just for the "statistics" people:
- a site verify without cache rebuild takes 5 seconds
- a site verify with the current approach ( rebuild ) takes 2 min 25 sec

So its so its ~30 times faster.