o Keep track of whether or not MB_TYPE_HANDLE tags are iBase_ENTITY_SET_HANDLE
o For tags read from file guess iBase_ENTITY_SET_HANDLE vs iBase_ENTITY_HANDLE

Notes:

Variable length tags are never passed back from any iMesh call that returns
a tag handle.  However, iMesh apps cannot create a tag with the same name
as an existing variable-length tag.  That is obviously suboptimal, but no
worse that before this change as previously the app would have failed as
soon as it tried to do anything with such a tag handle anyway.

iBase_ENTITY_SET_HANDLE vs. iBase_ENTITY_HANDLE is tracked using lists of
tag handles in MBiMesh.  This leaves open the possibility that a tag could
be deleted from underneath the iMesh API by using the MOAB API directly.
That isn't a serious problem because the tag lists stored in MBiMesh are
only compared with known good tag handles.  But it is possible that a tag
could get deleted and then the handle re-used.  I think this scenario is 
fairly unlikely, though.  As MOAB tag handles are now pointers, the chance
of one getting re-used is slim.  And there will never be a problem unless
there is mixed use of both the MOAB and iMesh APIs anyway.

If a tag of type MB_TYPE_HANDLE is created by reading from a file or
using the MOAB API directly, then the iMesh code must guess whether or
not it is iBase_ENTITY_SET_HANDLE or iBase_ENTITY_HANDLE.  This is done
using a potentially expensive check of all the tag values (including 
the global/mesh value and the default value.)  If all the values are
of one type or the other then the type will be noted for future reference.
If there are no tag values or the values are mixed, then iBase_ENTITY_HANDLE
will be returned but the type will not be noted.  Subsequent queries for
the tag data type will re-do the check in that case (with the hope that 
at least for the no-value case it will be less ambiguous in the future).



git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk@4574 6162379e-bd28-0410-9a7d-b7f4dcfcad3c