Support additional metadata in version tags

[timothyb89]

Version tags (especially for Docker images) often contain additional metadata about that entry in the repository. In most cases (at least that we care about) these are usually dash-separated tokens in the version, like python:3.6-alpine3.6.

In general we shouldn't automatically propose updates that would switch between different tags or "release trains". As an example, the bot generated an update to monasca-helm: monasca/monasca-helm#185

In this case monasca-helm's client chart is using "released" image versions with standard semver tags (monasca/client:1.6.0 - we'd probably consider this a null tag) and the bot tried to update it to use monasca/client:master-20170918-185757 (master tag). Since monasca/client:1.7.0 was also published we should have used that release instead.

This introduces some problems:

• determining tags for a version depends on the version number formatting (see also, versioning policies from Per-repository and per-module configuration #15)
• we'd need to store multiple current versions for every module from every repository - latest version per tag
• we'd also (maybe later) need some way to specify how+when dependencies actually receive updates (related to per-module configuration from Per-repository and per-module configuration #15). Behaviors might include:
  • semver-patch: only update z in x.y.z
  • semver-minor: either y or z in x.y.z
  • semver-major: always use latest available semver
  • semver-* could have additional policy options:
    • tagPolicy: sticky (default) only updates to matching tags (e.g. no updates to master from null), none ignores tags (current behavior)
    • tag: just lock to a particular tag
  • datever: (or something) use the tag with the latest embedded timestamp (for the master-{date}-{time} case)
  • last-published: current behavior