With this change a select few vtkObjects, including vtkBuffers,
vtkDataArrays, and common vtkDataSets can optionally be
constructed within in a potentially large memory space
provided by Memkind.

Memkind provides memory mapped buffers over any file system,
but ideally one mounted -o dax and backed by fast non-volatile
memory hardware like Optane. Applications set the specific
location early on via vtkObjectBase::SetMemkindDirectoryi().

To try it, turn on the new VTK_USE_MEMKIND cmake configuration
option and provide a path to link libmemkind. The option
turns on the new and very experimental code paths. Memkind, and
thus the option are only available under Linux.

In user code, to create vtkObjects in the extended space call
the ::ExtendedNew() function rather than the typical
::New() function. The TestMemkind test demonstrates and
exercises the feature. The implementation is that ExtendedNew()
turns on a static flag vtkObjectBase::UsingMemkind, that
forces constructors to use memkind_malloc() instead of malloc().
The UsingMemkind flag is protected behind an RAII control,
vtkObjectBase::vtkMemkindRAII() to make it safer to use correctly.

All vtkObjects remember where they were created by virtue of an
instance local vtkObjectBase::IsInMemkind flag. This is necessary
to control behavior at runtime in a few instances but mostly to
ensure that the correct free function, either memkind_free() or
free(), is called when the object's lifetime ends.

The temporal caching filter has been extended to optionally
take advantage of the new capability. The new
vtkTemporalDataSet::CacheIsInMemkind flag, tells the filter that
it should create it's copies of the data it receives in the
extended memory space. The flag is expected to be set before
the cache is exercises and should remain unchanged for the
duration of the program.

The new TestTemporalCacheMemkind test exercises this capability.