Feature/greedy algorithm

[kevinhkhuynh]

Implementing the greedy algorithm.

1. User constructs the greedy algorithm class, given it a domain of parameter points. (A set of CAROM::Vectors or doubles).
2. User requests a parameter point to sample. To keep things general, libROM does not return the Vector/Double corresponding to the parameter point, but an index to the parameter point set. The user should already have access to this since they supplied it when constructing the greedy algorithm class. If not, they can obtain it by calling the get method in the libROM class.
3. In another code base, the user creates a ROM for this parameter point.
4. User then asks greedy algorithm which point it should find a residual for. This is how the greedy algorithm decides where to create the next ROM. libROM gives that to the user as an index into the parameter point set.
5. In another code base, the user computes the residual and gives it to libROM.
6. Steps 4 and 5 repeat, until libROM returns a -1 for the next point. Meaning, we have decided on a new point to create a ROM at or we have not yet converged with a random subset of parameter points meeting the error threshold. We need to go back to step 1.
7. This process repeats until libROM returns a -1 for the next point to sample at step 1. The algorithm has converged and our ROM database is complete.

The greedy algorithm class does not maintain any basis for any ROMs. The user does this in their own code, since the greedy algorithm class does not need this information. The user only needs it to calculate the residual in step 5.

The user interface for this is a little complex since this does not really seem to be an algorithm, but more of a workflow. Any suggestions to simplify it are appreciated.

[kevinhkhuynh]

Ready for review.

[kevinhkhuynh]

Ready for review.

[chldkdtn]

@siuwuncheung @dylan-copeland Let's review and approve this soon.