RFC: getting rid of deprecated_hp_som_som_object_present

[Randolph Chung <randolph@tausq.org>]

Recently on gdb-patches there was some mention of this deprecated flag. 
I'd like to get some comments/feedback on how to clean this up....

Here are the parts of gdb that uses this flag:

- symtab.c defines this variable
- hppa-hpux-tdep.c initializes this to 0 for each newly created inferior
it also uses this to help determine if we should use the special hp c++ 
exception support
- hpread.c sets this variable to 1 if we read a file with HP debug 
information
- eval.c uses this to decide to punt if we try to do something with a 
pointer to member function, or to apply a bias for a pointer to member 
variable
- parse.c has a reference to this in a function named 
parse_nested_classes_for_hpacc, but this code apparently is no longer 
used anywhere in gdb
- valops.c uses this in value_cast to handle casting things from a 
pointer to member function/variable to an int or enum
- c-typeprint.c uses this to print extra info for "sized enums"
- cp-valprint.c uses this in cp_print_class_method to handle class 
member functions (I think)

Most of these have to do with how gdb handles c++ methods and member 
variables, which makes me think that perhaps we should add some hooks to 
the cp-abi layer to handle the type conversion logic. This takes care of 
eval.c, valops.c, and maybe cp-valprint.c

I'll have to dig through some cvs history to figure out what we want to 
do with the bits in parse.c

hpread.c should probably just set the current auto c++ abi type.

what should we do with c-typeprint.c?

I notice that HP's wdb has better support for some of these cases. If we 
were to clean up the above it will be worthwhile to look through wdb and 
try to merge in some of the logic there (mostly to deal with member 
functions)

Any thoughts? Is this even worth touching/fixing?

randolph