Persistent team policy

[kuberry]

Currently, the ParallelManager creates a team_policy instantiation each time a functor is requested, without persistence. The next time a functor is called, it needs to be done again.

Particularly for within the GMLS class, this means that many scratch allocations are being made that could be made once for all time if this were made persistent. Previously the ParallelManager class has been passed around, keeping track of scratch space and levels, with a copy constructor that consists only of ints/doubles. This will no longer be the case if the PM is managing the policy and its persistence.

[kuberry]

Addressed partially by #257 where team policy is reused.