Proposed patch to fix plpgsql's handling of block labels

Per recent discussion, plpgsql's handling of block labels is not very
desirable: it will recognize unqualified identifiers as being block
labels even in contexts where a block label is illegal, and it will
prefer a match involving a block label over one that doesn't, even
when the second match is in a more closely nested scope and so should
take precedence over the outer-block match.

It is important to fix this for 8.3 for two reasons:

* Our introduction of the function name as the outermost block label
has created a risk of breakage of existing functions that use a
variable named the same as the function, as illustrated here:
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00423.php

* We had not documented the possibility of using a block label as a
variable qualifier in any previous release, so it's at least somewhat
unlikely that anyone is depending on the current behavior. (If there
is any code that's using qualification at all, it's probably been
imported from Oracle and expects the Oracle behavior.) But if we don't
fix it now, there may be code depending on the bogus behavior by the
time 8.4 rolls around.

The patch separates lookup of block labels from lookup of variables,
which is possible since we always know which type of name we want to
find. There's also some marginal cleanup of ugly/inconsistent coding
in plpgsql_parse_wordtype and friends.

Comments, objections?

regards, tom lane