(#5318) Always notice changes to manifests when compiling.

When we are asked to compile a catalog we need to update the set of known
resource types, along with the node declaration, from the pool of manifests on
disk. This is, obviously, a per-environment pool of resource types.

To reduce the scope of the race where an update to those manifest files on
disk can be updated during a compilation, we tried to cache the set of known
resources in the current thread at the start of compilation, then flush it
after compile finished and used the cache unconditionally if it was set.

Theoretically, this would assure us that we would parse the set of manifests
once, use them for the entire compile, flush the cache, and then carry on.

Practically, this was enforced as described: flush *after* the compile, assume
this would mean that it was clear at the start of the next compile.

That presumably worked more or less right until a change was made to push
extra data into the catalog at the start of the 2.6 series; that made
serialization of the catalog depend on the pool of known resource types.

When that happened we would reload the cache (and reparse the manifests)
during serialization, but after compilation ... and leave that in the thread
cache, so the precondition for the compiler was no longer true. It would see
the cache as of the end of the previous compile run, not the start of the next
compile run.

This, in turn, was what made Puppet wait for multiple runs of the agent before
showing you a change in your manifests under Passenger, but *not* under
Webrick: Passenger would reuse the same thread for the next request, cache in
place, while Webrick would create a new thread and (by side-effect) "flush"
the cache as the compiler expected.

To minimally fix this, with as little change of side-effect as possible, we
move the cache flush from after compile runs to before compile runs.

This might have minimal memory cost until another compile request runs in the
same thread, because we cache the data longer, but most models won't cause
that to be too much trouble.

Reviewed-By: Matt Robinson <matt@puppetlabs.com>