Add PrimitiveId data structure

[nilsvu]

Proposed changes

This data structure wraps a generic type T and provides a value() member function that allows it to be used by ObservationId.
I intend to replace my LinearSolver::IterationId with a PrimitiveId<size_t> and also use it as the type for the new NonlinearSolver::Tags::IterationId, as well as other components of the elliptic solver that need to keep track of a step number, such as AMR and Multigrid cycles.
I understand a PrimitiveId<double> is also useful for horizon finding and other components, so I'd appreciate some feedback. Putting this in as a draft PR for now to make sure we agree on the design before finalising this.

Types of changes:

• New feature

Component:

• Code

Code review checklist

• The PR passes all checks, including unit tests, clang-tidy and IWYU.
  For instructions on how to perform the CI checks locally refer to the Dev
  guide on the Travis CI.
• The code is documented and the documentation renders correctly. Run
  make doc to generate the documentation locally into BUILD_DIR/docs/html.
  Then open index.html.
• The code follows the stylistic and code quality guidelines listed in the
  code review guide.

[kidder]

1. I do not like the name as Primitive already has a meaning (Primitive vs Conservative)
2. I do not see the motivation for this; why not just take IterationId outside of the LinearSolver namespace and reuse it. You could also add an increment operator to it if it is convenient

[wthrowe]

Why don't we just remove the .value() call from ObservationId and make people pass in a double? In the long term at least for evolutions I think all the observations are going to be identified by doubles anyway.

[nilsvu]

• If I could pass a size_t or a double to ObservationId that would eliminate my need for this type. However @nilsdeppe didn’t like that if I understood him correctly.
• Please suggest a better name @kidder, I couldn’t think of a better one
• Moving IterationId out of the LinearSolver is precisely what this PR does. It makes the type generic so that it may be used by other code.

[kidder]

Why can't you use IterationId?

[wthrowe]

Could you just explicitly do static_cast<double> when you need an identifier rather than wrapping in a class that just exists to do that?

[nilsvu]

@kidder I can name this type IterationId, specialize it to size_t and place it in DataStructures, that’s fine with me. I was told that other code needs a similar type for double, which is why I made this generic. If ObservationId could take a size_t or double directly I wouldn’t need this type at all. Please make a decision and/or ping me to talk in a hangout

[nilsvu]

@wthrowe yes, only ObservationId needs a value() member function

[wthrowe]

But we could change that, as I suggested above.

[nilsdeppe]

I'm pretty sure changing observationid to take a double is what we had actually agreed upon in a call with CalTech.

[nilsvu]

Yes let’s do that. It means I can use a plain size_t for the LinearSolver::Tags::IterationId and for similar tags.

[nilsdeppe]

@markscheel would changing ObservationId in this manner make your life difficult right now?

[nilsvu]

Superseded by #1408