Elastix did not call AfterRegistrationBase before throwing exception
and consequently did not clean up xout. This resulted in undefined
behaviour and more or less random segfaults if the ElastixFilter was
called again after an exception was thrown. This would happen _even_ if
the filter was completely destroyed and a new filter was instantiated.
This possibly fixes SuperElastix/SimpleElastix#123 and  an issue
previously reported by @coertmetz but need more testing. NOTE: This
does not change the fact that elastix is not thread safe which might
still be an issue (also reported by @coertmetz).

…suggestd by @coertmetz, and do it directly, instead of AfterRegistrationBase as suggested by @stefanklein