Conditional munging of default views can break other views

Originally pointed out to me by greggles in IRC and posted at #930664-3: Handle d.o customizations of views in code, not the DB ...

Once I deployed #921210: Fix performance of "My issues" some other views were getting very weird behavior, e.g. tons of entries for the same issue, etc. I immediately thought "sounds like tracker2_user is being used, but WHY?". Well, because the way I was conditionally munging the default views was a little sloppy. I was doing stuff like this:

if (function_exists('tracker2_views_api')) {
  $sorts['changed'] = array(
     // some tracker2 stuff
  );
}
if (module_exists('search')) {
  $sorts['score'] = array(
   ...
  );
}
...
$handler->override_option('sorts', $sorts);
...

That's all fine, but when the next view is loaded during hook_views_default_views(), the $sorts array has all this stuff from the last view in it.

Up until now, that hasn't been a problem, since all these views were doing the same thing. ;) So, the array keys were all the same, and the values, so it all just silently worked.

However, #921210 is the first time that these default views have divergent sort handlers like this. So, it's the first time that sorts from one view were leaking into another.

And, the way {tracker2_user} works, once you JOIN on it, you *MUST* have a filter/argument by UID, or you get the weird results. Basically, we never want to use {tracker2_user} unless we're doing a "My issues" style view to show you stuff you participated in.

Fairly trivial fix coming soon, stay tuned. I just need to make sure I always clear out variables like $sorts or $filters and such before using them, since I forget that all default views, even if they live in separate .view.php files, are all running in the same function scope.