Refactor of memory management

[Yurlungur]

A bug in downstream code singularity-eos prompted me to run valgrind on Spiner. I discovered a number of issues with Spiner's pseudo-reference-counting where it tried to manage its own memory on the host but gave up on the device. This design had several problems:

1. It was conceptually difficult to track and bug-prone.
2. A DataBox that managed memory could not go out of scope. If it did, all DataBoxes that depended on it would be pointing at unitialized memory.

I therefore re-design DataBox memory management in this PR. I do the following:

1. DataBoxes can allocate memory. They free memory before re-allocating, but otherwise never free memory.
2. Freeing memory must be performed externally via the DataBox::finalize() or free(DataBox&) methods, which release allocated memory.

This provides several advantages.

• First, it avoids the aforementioned problems.
• Second, with a little tracking, we can now control where a DataBox allocates memory more finely. I now provide constructors and "resetter"s that can tell DataBox where to allocate. You can allocate on the device via, e.g.,

  Spiner::DataBox db(Spiner::AllocationTarget::Device, n3, n2, n1);

  and you can always free via

  free(db);

  no matter where the data is located.

• Finally, the free() mechanism allows to subsume our databox to smart pointers and reference count them that way if desired. To enable this, we provide the Spiner::DBDeleter class defined as

  struct DBDeleter {
  template<typename T>
  void operator()(T* ptr) {
    ptr->finalize();
    delete ptr;
  }
  };

  This can be used as, for example,

  std::unique_ptr<DataBox, Spiner::DBDeleter> pdb(new DataBox(Spiner::AllocationTarget::Device, N));
  auto db = *pdb;
  portableFor("Just do something", 0, N, PORTABLE_LAMBDA(int i) { db(i) = 2.0*i; });

  which will automatically garbage collect the device memory when pdb goes out of scope.

Thanks to @jdolence and @dholladay00 for useful discussions while I chased this down. Thanks @brryan for the idea about the custom deleter for the shared pointer. @jdolence @dholladay00 please take a look at this and let me know what you think. I'd like to merge it in quickly. Then I will need to update singularity-eos to utilize the new API.

[Yurlungur]

I also replaced a large fraction of boiler plate in the class with variatic templates. Although the templates are a little harder to read, they improve readability by reducing the number of function overloads by a factor of 6 in some cases.

[dholladay00]

I'm a fan of these changes. I know that variadic templates can be somewhat impenetrable, but I think this is an excellent usage of them and the reduction in SLOC is a big plus in my book.

There was a comment about one of the functions and that one I need further clarification on before merging if that's alright.

[Yurlungur]

Thanks @dholladay00 ! Yes, let's discuss your comments a bit inline before proceeding.

[Yurlungur]

Thanks for all the feedback @dholladay00 ! I think I've addressed all concerns. Can you click approve if you're happy for now?

[dholladay00]

I don't see an approve button.

[dholladay00]

I don't see an approve button.

I found it

[Yurlungur]

Travis CI is refusing to run jobs. I'm merging.