hdf5_der

[svn-r28579] Checkin of fixes to more bugs uncovered by investigation of 
SWMR-95 -- specifically:

1) Code in H5C__flush_single_entry() taking down all remaining 
   flush dependencies before an entry is destroyed.  

   Replaced this with code asserting that all flush dependencies 
   have been taken down by the cache client as required by the 
   protocol for managing flush dependencies.  This exposed:

2) Both the object header proxy and the object header continuation
   chunk cache clients were failing to track their flush dependency
   parents, and thus were relying on the above code in 
   H5C__flush_single_entry() to take down their flush dependencies
   instead of handling this issue in their notify callbacks.

Fixing item 2 for the object header continuation chunks was straight
forward, as each object header continuation chunk can have at most 
one flush dependency parent.

However, there is no upper bound on the number of flush dependency parents
for an object header proxy (one must be an object header -- any additional
flush dependency parents must be object header continuation chunks).
This said, in most cases object header proxies have only one flush 
dependency parent.

To handle this, I adapted Neil's code for tracking multiple flush 
dependency parents in the metadata cache for use in the object header
proxy, with the difference that I set the initial array size to 1 
(Neil uses 8).  To change this, modify H5O_FD_PAR_LIST_BASE in H5Opkg.h

Potential issues with this fix:

1) While the fix passes the existing regression tests, I don't believe
   these test the code for tracking multiple flush dependency parents
   in the object header proxy adequately.  

   From discussions with Quincey, I gather that the obvious way to 
   do this is to add and delete large numbers of properties to/from the 
   object header, forcing increases and decreases in the number of 
   object header continuation chunks.

   However, as I am unfamiliar with the layout of the SWMR test code,
   it seemed inefficient for me to address this issue -- hence I gather 
   that it will be handled elsewhere.

2) My fix tracks both pointers to flush dependency parents and their
   addresses.  As the addresses are used purely for sanity checking, 
   once we are reasonably confident of my fix, the code can be 
   modified to either to remove the address tracking and the associated 
   sanity checks completely, or to maintain the addresses in debug 
   builds only.

   Note that the address tracking code presumes that object headers 
   and object header continuation chunks cannot change addresses.  If
   this ever changes, the sanity checking code will complain.

Tested (debug only) serial and parallel on Mercury, serial on Jam.