Fix cellparents interpolation

[Da-Be-Ru]

As pointed out in #53 , the use_cellparents flag in lazy_interpolate doesn't seem to work right.

The issue was that for higher order interpolations, the MomentInterpolator's QPInfo object was initialized with a cell index of 1 and never actually filled with any useful info. @pjaap and I updated it to fill it with simply the first best incident cell info (extracted from EdgeCells).

Not sure if I did it right or if there are cases and assembly types that need special treatment.
This also contains your revisions, @chmerdon to the evaluate! functions in lazy_interpolate which made a slight difference in allocations.

I tried to check the speedup for a nasty grid case (b/c on convex domains this hardly makes a difference, lastnonzerocell is simply very good there). But this revealed another problem (see #55).

HINT: ExtendableGrids needs to be checked out to #100 for this to run

[Da-Be-Ru]

Additionally, using #101, we get some stable behaviour with e.g. this kind of minimal test similar to Example290 with some nasty ring sector:

julia> xgrid = ringsector(0.5:0.1:1., linspace(0.,2π-π/4,10);eltype = Triangle2D); xgrid = uniform_refine(xgrid, 3); source_space = FESpace{H1Pk{2,2,2}}(xgrid); target_space = FESpace{H1Pk{2,2,1}}(uniform_refine(xgrid, 1; store_parents = true)); source_fevector = FEVector(source_space); interpolate!(source_fevector[1], (result,qpinfo) -> (x=qpinfo.x; result[1] = sin(4 * pi * x[1]) * sin(4 * pi * x[2]))); target_fevector = FEVector(target_space);

julia> @btime lazy_interpolate!(target_fevector[1], source_fevector; use_cellparents = false)
  19.943 ms (188336 allocations: 7.14 MiB)

julia> @btime lazy_interpolate!(target_fevector[1], source_fevector; use_cellparents = true)
  18.271 ms (148128 allocations: 6.61 MiB)

Surprisingly, the speedup is not very great, though and should probably be looked into at some point.

[Da-Be-Ru]

It seems that the upstream test for Example207's test fails because the interpolation of the boundary data into $P_0$ space delegates the evaluation to the cells adjacent to the Dirichlet boundary faces.

The MomentInterpolator is instantiated with ON_CELLS, while the evaluate! call is of course run with a slice of the cells corresponding to the bfaces in the associated boundary region.

Should be easily fixed by setting the itemcells in that case to 1:nitems (being the number of sources of CellNodes in that case which is just the cells themselves). A little unsure if that's general enough, but that'd at least fix Ex207 and similar delegations to slices on boundaries if I'm not mistaken.

[Da-Be-Ru]

It would seem this runs through fine now. I added a CHANGELOG entry as well.
Perhaps we can merge this now and register?

[chmerdon]

Looks good (apart from the suggestions below), thanks!