Attempt to simplify/generalize coupling

[majosm]

Deprecates operator definitions in thermal coupling code and refocuses the API on setting up the interface boundaries. This allows for more flexibility on the driver side (e.g., more than 2 volumes, easier access to gradients, etc.).

cc @tulioricci

Questions for the review:

• Is the scope and purpose of the PR clear?
  • The PR should have a description.
  • The PR should have a guide if needed (e.g., an ordering).
• Is every top-level method and class documented? Are things that should be documented actually so?
• Is the interface understandable? (I.e. can someone figure out what stuff does?) Is it well-defined?
• Does the implementation do what the docstring claims?
• Is everything that is implemented covered by tests?
• Do you see any immediate risks or performance disadvantages with the design? Example: what do interface normals attach to?

[majosm]

@tulioricci, @MTCam I think this is ready for a look through. (I'll do the production merge after.)

[tulioricci]

Why don't we remove it right now and make the warning says that it is being ignored?

[majosm]

Done in 6cd4494.

[MTCam]

Overall this is great. Only one slight concern from my perspective, but nothing preventing merge I think.