Expose mesh data, add plotting capability.

[greschd]

Add elemental_data and nodal_data attributes to tree objects, which fetch the
data from the mesh query API.

The returned objects have a method to_pyvista, to convert to a plottable object. Currently,
this requires the Model.mesh to be passed in; we may consider how this can be avoided.

Optionally, a component (name to be improved) can be passed, to select which data to
add to the PyVista mesh. If a vector component is selected, the data is converted to arrows.

The possible string constants for component are exposed in the ElementalDataType and
NodalDataType enums, which are auto-converted from their protobuf equivalent.

Helper classes and functions for wrapping mesh query data are defined in _mesh_data.py:

• a base class MeshDataBase which implements to_pyvista, as well as the construction
  from a mesh query response
• base classes ElementalData and NodalData, which are the classes to be used to define
  the mesh data classes for each tree object type
• property helpers elemental_data_property and nodal_data_property, for defining
  the elemental_data and nodal_data properties, respectively.

The mesh data itself is exposed in a separate mesh on the Model. Its class MeshData
also implements a to_pyvista method.

Add a __slots__ class attribute in some places where it was missing, to disallow setting
attributes that are not explicitly defined on tree objects.

[greschd]

Note: tests are still missing, follow-up item #234.

At least, some of the mesh query functionality is exercised in the example.

[janvonrickenbach]

Having this as a member function closely couples the MeshDataBase object to pyvista. Would it also be an option to make the pyvista conversion a free function?

[greschd]

As discussed: The free function approach has the benefit of decoupling the tree objects from PyVista. However -- at least as it currently stands -- it's a bit tricky to make it both easily discoverable / documented, and make mypy happy. This is mostly for two reasons:

• the return value depends on whether a MeshData, or ElementalData / NodalData is being passed
• the ElementalData / NodalData case has additional keyword arguments

For now, to avoid a more complex solution, we stick to the method approach. If / when the data containers need to be convertible to multiple different plotting / serialization formats, we can revisit this to avoid bundling all responsibilities into a single class.