Restore the ability to associate a location list with a data member of a class.

Changes
-------

In Section 5.5.6, fourth paragraph (of *Draft 3*) replace the last two
sentences, which now read

   "... If the value is a constant, then the value of that constant is
   the offset in bytes from the beginning of the structure or class to
   the beginning of the member. Otherwise, the value must be a location
   description."

with

   "... If the value is of class constant, then the value of that constant
   is the offset in bytes from the beginning of the structure or class to
   the beginning of the member. If the value is of class block, then
   the value is a DWARF expression, whose evaluation gives that same offset.
   Otherwise, the value can be of class loclist, in which case the offset
   is specified by the associated location list."

In Figure 18, change the DW_AT_data_member_location line to read:

   DW_AT_data_member_location 0x38 block, constant, loclist


Discussion
----------

Now that we approved 410.3 (as revised), think back to 000302.1, in which
we changed the definition of a "constant" class operand for a data member
location from being an offset into the location list section to being an
immediate offset in the object. With the above reformulation, we can have
it both ways!

This eliminates even the unlikely possibility of forcing an incompatible
change on some implementation that is currently supporting split lifetimes for
data members or of denying that possibility in the future. Such an
implementation must necessarily use DW_FORM_data4 (and in the 64-bit file
format, would have to use DW_FORM_data8) to refer to the .debug_loc section,
which leaves the other constant forms to be given some other interpretation.

Of course, we as DWARF designers have to keep this in mind if and when we
want to specify any other attribute as allowing both a constant and a
lineptr, loclist or macptr class operand to make sure the "removal" of the
DW_FORM_data4 and DW_FORM_data8 forms from the constant class for that
operand does not pose a problem. (So far DW_AT_data_member_location is the
only case where this issue arises.) Since DW_FORM_sdata and DW_FORM_udata
are still available as constants and they can represent any compile time
constant values that DW_FORM_data4 and DW_FORM_data8 can represent, this
is unlikely to ever be a problem.

Approved.