Thanks, merged.

I left one comment, bu otherwise this looks good to be merged from my side.

All sounds good and in keeping with how I remember our discussion in yesterday's
live meeting.

I made a few more small changes to PatternInformation.

For the time being, I'd suggest to keep PatternInformation and
PatternCollectionInformation independent from each other even though they are
similar to each other and PCI could possibly re-use PI as suggested by Florian.
That way, all of the generators have a similar interface for now.

I think that we should deal with changing the way how we pass around pattern
collections, possibly with their PDBs, in a separate issue. (We discussed that
it would be good to have patterns and PDBs together, both for making changes to
the collection and for possibly avoiding to store the pattern next to the PDB
and in the PDB).

I added this to the agenda.

Jendrik again brought up the question whether we actually want to keep
PatternGenerator next to PatternCollectionGenerator. I suggest to discuss this
offline at some point; maybe at the next Fast Downward meeting next week.

I addressed them.

I left some comments.

I implemented my suggestion:
https://bitbucket.org/SilvanS/fd-dev/pull-requests/44/issue892/diff

Any reviewers?

I'll stay out of this discussion for now. I don't know the code well enough to
have an opinion.

For users like the PDBHeuristic, having a distinction between a pattern or a
collection generator makes sense. Also for use cases like ours where a
collection generator repeatedly calls to a pattern generator. So I think would
slightly favor to keep the distinction but to not only return a pattern, but a
wrapper that allows to also return the PDB.

I like the idea. This raises the question whether we still want
PatternGenerators at all since they could just become PatternCollectionGenerators.

Working with pattern generators recently, I realized that even though some of my
generators may compute a "singleton pattern collection", i.e., a simple pattern,
it it more convenient to actually compute a collection containing a single
element because this allows using the PatternCollectionInformation interface
which in turn allows keeping the potentially already computed PDB corresponding
to the pattern. Since the only pattern generator currently contained in the
default branch (besides the manual one) is the greedy one and this isn't
frequently used to my knowledge, I suggest changing the interface of
PatternGenerator to either PatternCollectionInformation, or, probably more
properly, to something like PatternInformation, where the generator may include
the already computed PDB if it likes to.