DynamicView with host size grow

[bathmatt]

@hcedwar and I talked yesterday about this. He agreed that Kokkos will add a dynamic view like the one that is there but growable on the host. This won't use the memory pool and should be able to deal with fragmentation. It will also not require that the scalar type be a 2^n size. So, I can have

class my_class { int a, b,c;}
DynamicView<my_class*> my_data( initial_size, chunk_size=1024);

and I can
my_data.resize(new_size);

[hcedwar]

@crtrott @ndellingwood @bathmatt
This is a must-do for Matt by the February 2018 milestone. I suggest Nathan.

[ndellingwood]

@bathmatt I started working on this feature request and have an initial WIP PR #1378. I'll summarize some of the changes (API and behavior), could you give some feedback on the changes and whether this direction meets your use cases or needs changes?

1. resize can now only be called on the host outside of parallel_* calls.
2. resize_serial member function is used for resizing; the name was not changed nor was the API
3. Use of memory pool was removed, resize_parallel member function removed
4. DynamicView API (current PR) would require the 3 following arguments: (1) label, (2) chunk_size, (3) extent_upperbound, so

DynamicView< Scalar*, ExecSpace > dv( "dv", chunk_size, extent_upperbound) ;

I can add a fourth argument initial_size as well, and if I make it optional I can default it to 0 but it would need to be the final argument to the constructor.

The extent of the DynamicView (provided via resize) does not need to be 2^n, though internally the chunk_size will rounded up to a nearest power-of-two for faster bit operations during indexing and resizing.

The extent_upperbound is an upperbound on number of entries the DynamicView will receive. This was added to avoid having the inner array of pointers to chunks needing to be resized, which could be problematic in the case where there are multiple copies of a DynamicView and resize is called (where the array of pointers to must be resized) because only the DynamicView on which the resize is called will have the new array. Working around this to allow resize of the array of pointers would likely come at a performance hit to enforce some type of synchronization of the array of pointers between the views.

[crtrott]

Just pushed this into develop.