terms in project taxonomy with same name can confuse project overview

as reported by fgm/osinet...

in project_page_overview(), if there's a term as the first argument (e.g. someone goes to [site]/project/Modules), there's an SQL query to grab the term from the DB based on the name. unfortunately, if someone defines some 2nd-level taxonomy terms that have the same name, you can get non-deterministic, weird behavior, since you might get a different actual taxonomy id (tid) each time you view the page.

what we need is to ensure we're *only* looking at top-level terms in this case, since that's what we're expecting that first argument to be. none of the code is written to expect that the URL might match a 2nd level term. for example, check out how different these 2 pages are:

1. http://drupal.org/project/Developer
2. http://drupal.org/project/Modules/category/59 (which you get to via http://drupal.org/project/Modules -- "browse by category" tab -- select "Developer"

sadly, project.module is pretty careless with the URLs, and there are all sorts of potential collisions. for example, if you happen to goto http://drupal.org/project/Event you get the event module, not an overview of all modules in the "Event" category. :(

anyway, it seems dangerous to just lookup all terms that match a given URL path element. we should only look at top-level terms. then, the resulting pages all look like they're supposed to, there's no chance of name collision between terms (only between projects and terms, but that's another story *sigh*), and you at least get deterministic behavior if you've got 2nd level terms (think "Miscellaneous") that match a top-level term.

so, we just add an INNER JOIN {term_heirarchy} to our query, and only grab a top-level term matching the URL path element.

i'll admit, this bug is hard to reproduce, so it might not be obvious when testing this patch that anything's better. ;) but, fgm insists he saw this in the wild, and he convinced me it's a bug...