Fix Views2 support

Nate, this patch fixes several problems in our Views2 support.

(The patch isn't really 20K. When I run 'cvs diff' I asked it to include the whole file in the output, because I wanted you to have the whole file before you.)

Main things fixed:

1. I removed the:
   

     $join->definition['extra'] = array(
       ...
       array(
         'field' => 'content_type',
         'alias' => $this->alias,
         'value' => $flag->content_type,
         'numeric' => FALSE,
       ),
   

   This extra join info was meant to restrict the join to matching content_type's on both sides, but this isn't needed anymore, because the flag ID itself enforces this match (flag_views_flag_config_form() returns only compatible flags). (Besides, variable '$this->alias' didn't exist and gave PHP warning.)

2. The query() method of the relationship handler stored the flags in $views->flags[] but this had several problems:
   • If Earl implements query caching, query() most probably won't get a chance to run.
   • We accessed this $view->flags[] in the field handler's init(), but since init() executes before query() this array doesn't exist yet.
   • No need for this extra storage: It's possible to get to the flag by reaching out to the relationship handler.

   So instead I wrote a get_flag() method on the field handler.

3. The node's 'type' field was pulled in using 'additional_fields', but this is not possible, because fields registered in this array are linked through the current relationship --which is our flag_content table. Since we haven't told Views how Node connects to this table, linking won't work. So we now pull these fields into the parent relationship.
4. $values->nid, and $values->cid were used, in render(), for finding out the content IDs, but these point to the root relationship. Our flaggable content may reside in some other relationship, so, besides the node type above we now also pull in the content ID.
5. In the default view ('My bookmarks'), the 'flag_content_rel' relationship must come before the 'uid' one, because the latter uses the former and Views initializes them (that is, calls their set_relationship()) in order. I'm speaking of the '$handler->override_option('relationships', ...)' array.