Restructure fork opening, fix adouble refcounting

Restructure fork opening, fix adouble refcounting

Fixes Bug ID 3559783

The bug is caused by passing ADFLAGS_NOHF to ad_open() when opening a
files data fork. For files without metadata then ad_open() doesn't
return an error for the ADFLAGS_HF request to open the metadata. As a
result of the successfull ad_open return AFPFORK_META is set in the
fork struct, which implies the meta is open. Later afp_close looked at
that flag and added ADFLAGS_HF to ad_close flags, resulting in a
refcount decement of 2 although the ad_open only incremented by 1. Eg
opening such a file twice, then closing once, close the fork. Later
operations on the other still open fork fail.

afp_openfork opens the fork and metadata in one call to ad_open which
lead to an insane if/else and error checking code path.  I've
seperated this in two distincs calls to ad_open(): the first opens the
fork (data or ressource), the second opens the metadata. This gives a
cleaner code path but it required a subtle modifications to the way we
refcount and flag forks as open inside ad_open: currently we use the
fd and it's recount but these do not differente between open data and
metadata in the case of adouble:ea as both use the data fork handle,
fd and it's refcount.  Now we add real refcounting for the forks
different from the recount on the file fd by adding three refcounting
variables to struct.adouble and change the AD_XXX_OPEN macros to use
these.

Added test-suite testcases 3, 4 and 7.