Inconsistent results deciding series and -v parameters

[Robie Basak]

Some components, like lint, changelogify, and build, need to know the following things:

1) changelogify: what to put in the series field
2) build: what chroot to use
3) build: what -v argument to use (eg. for an Ubuntu merge)

To be consistent on this, we should have a function that takes the current state and answers this question.

Then the implementation of the function becomes an architectural decision that we need to make (deferring for now).

Inputs to the function would be:

Where HEAD is.
The commit graph and branch pointers.
Any overrides provided by the user.

We need to decide how the function will work, what assumptions it will make, and what defaults can be overridden to change its behaviour. To design this we'll need to take into account the set of use cases that we understand so far.

This decision may result in the change of current behaviour as well as CLI changes (eg. to replace --for-merge and --target-branch)

Use cases (please add more as needed):

Ubuntu developer doing a package merge
Ubuntu developer doing a bug fix to the development release
Ubuntu developer preparing an SRU
Some user trying to rebuild a currently published package (HEAD is on the same as a series branch pointer)