Include parent classes in process name/class reverse lookup

[benbovy]

• Closes Allow re-linking variables at Model creation #24
• add tests
• update doc
• add release notes

A possible way to customize processes is to use class inheritance. However, a current limitation is that foreign variables hard-code external classes, making it difficult to customize a model by replacing a process class by one of its sub-classes.

This PR address this issue by also including parent classes in the process name/class reverse lookup that is used to link foreign variables to their corresponding process when building a new model. Using the example in the docs, it is now possible to do something like:

@xs.process
class AlternativeGrid1D(UniformGrid1D):
    """Give number of nodes instead of total length as input."""

    spacing = xs.variable(description='uniform spacing')
    nnodes = xs.variable(description='number of nodes')
    
    length = xs.variable(intent='out')
    x = xs.variable(dims='x', intent='out')

    def initialize(self):
        self.length = (self.nnodes - 1) * self.spacing
        super(AlternativeGrid1D, self).initialize()


# no error "Process class 'UniformGrid1D' missing in Model"
alt_model = model2.update_processes({'grid': AlternativeGrid1D})

In the example above, the foreign variables declared in other processes of alt_model are now correctly linked to the 'grid' process even if they were declared like xs.foreign(UniformGrid1D, 'x'), as AlternativeGrid1D inherits from UniformGrid1D.

One drawback (and possible breaking change) is that linking foreign variables is ambiguous when both conditions below are met:

• two different processes in a model have a common class in their MRO (except object)
• a third process have a foreign variable that links to that specific class

For example:

 # this gives an error
alt_model = xs.Model({'grid': UniformGrid1D,
                      'grid2': AlternativeGrid1D,
                      'profile': ProfileU,
                      'init': InitUGauss,   # does init.x refers to grid.x or grid2.x?
                      'advect': AdvectionLax})

While the example above doesn't make any sense, I can't think about a real case where this should happen.

This feature is quite robust IMO, but it should be considered as experimental.