Use UFL for guessing quadrature order

1. ~~In order to test this branch you need to apply the patch in patch/ufl/ufl.patch to ufl. At the moment estimating degree in UFL doesn't work if there is a FunctionView followed by a ReferenceValue. This of cousre happens in stokes stress numdiff (where else?). That leads directly to the question: Should we keep that patch and introduce new version madness or should we do something else. This is the reason for WIP.~~  
 With the estimated polynomial degree from the metadata method the patch is not necessary anymore.

2. ~~The other interesting part is the behaviour of estimate_total_polynomial_degree from UFL. If you estimate the polynomial degree of Laplace without going to the reference elements for linear basis you get 0 (makes sense). If you go to the reference element you get 1. For poisson going to the reference values also adds 1 to the estimation. It is not obvious what you want to have but this seems a bit strange. Maybe we should print (or make it possible to print) the estimated degree?~~  
 This also simply gives the quadrature order you would expect from the weak formulation.

3. We have to look at our expressions at some point. Right now we give them order 0 if cellwise constant or order 1 if not. This kind of depends on the whole how to describe everything in the DSL. So it probably makes sense to postpone ;)...

This closes issue #38.

See merge request !40

Very wild, totally WIP.

Note: needs ufl patch

Cleanup/import on top

Move some import statements to the top of the file.

Note: This merge request includes a small bugfix. In some mysterious way an import was wrong after the last merge request. The strange thing is: I'm pretty sure I removed my build directory and tested the feature before merging. After merging and going back to master it didn't work anymore. Maybe I didn't delete the build directory but it is strange nonetheless.

See merge request !39

Feature/code restructuring

All the restructuring stuff we talked about.

Tested.

See merge request !38

refactoring pullback loopy update

This MR will supersede !34 and !27 as I created a big mess while working on those two.

See merge request !36

We do not need it.