RFC: Add language parameter to all parse.c:parse_* functions

[Joel Brobecker <brobecker@adacore.com>]

This is a followup to:

    http://www.sourceware.org/ml/gdb-patches/2010-05/msg00221.html

I think we all agree that depending on the current_language global to
determine which language parser to use is bad.

As a first step, we need to add language parameter to the parse
routines in parse.c.  Here is how I will do this, if that's OK with
everyone: I will add the new parameter, and then review each caller
trying to determine if there is an obvious language we can use.
Otherwise, I will use current_language as the parameter.

Normally, this should at worst keep things as they are today (ie:
the current_language gets used).  But we would then stop relying
on this global inside that unit.  We can then try to reduce the number
of uses of current_language wherever appropiate based on necessity
(when one finds a bug or works on the code).  Any objection?

Also: We have various parse routines declared in other modules,
most notably eval.c:parse_and_eval*.  It's unclear whether they also
need to be updated to take a language argument - each function probably
needs to be reviewed individually. For instance "parse_and_eval" most
likely need to take a language as an argument, but it's less clear for
parse_and_eval_address (I think it would be better to, since an Ada
user might write an address as 16#deadbeef#).  I propose to deal with
that as a separate patch.

-- 
Joel