Vector and supporting classes update

[pelesh]

Description

Implement several enhancements to the Vector and MemoryUtils classes needed to optimize GridKit model evaluation performance and portability.

Proposed changes

This PR provides (partial) support for #452 and includes:

• Policy-based hardware backend for CPU and placeholders for CUDA and HIP backends implemented in MemoryUtils class.
• Use C++11 move features (constructors and assignment operators) in DependencyTracking::Variable class to improve performance.
• Added size guards to multivector methods that lacked them.
• Default vector constructor is now the constructor that creates a multivector with one 0-length vector.
• resize method now can resize to a value larger than the original capacity to allow for instantiate now, allocate later.
• MemoryUtils are moved out of LinearAlgebra directory.

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• I have updated CHANGELOG.md to reflect the changes in this PR. If this is a minor PR that is part of a larger fix already included in the file, state so.

Further comments

A few questions that we should probably address in this PR, as well:

• Should we always allocate host mirror when we allocate data on GPU?
• When we allocate Vector data should we mark it updated? Should we initialize it?
• Should we remove setData functions and allow creating vector views only through constructors (and optionally factories)?

[pelesh]

CC @alexander-novo @abdourahmanbarry

[lukelowry]

Looks good to me one minor import note for completeness but otherwise seems like an improvment!

[lukelowry]

Can I preemptively rebase my other branches onto this?

[alexander-novo]

@lukelowry If it’s for the sake of not having to rebase later, the commits that end up in develop will be different so you’ll still have to rebase against develop later.

[alexander-novo]

Since this is not namespaced, it will conflict with other definitions of MemorHandler - such as with ReSolve