%{source-date-epoch} is not set to the last modification time of an element's sources

# Description
`%{source-date-epoch}` is currently a constant value set to 2011-11-11 11:11:11 UTC. Projects such as freedesktop-sdk commonly use this variable to define the `$SOURCE_DATE_EPOCH` environment variable inside the sandbox, thus allowing reproducible builds.

However, according to the established spec, `$SOURCE_DATE_EPOCH` should be set to the modification date of the source, as its name suggets: (from https://reproducible-builds.org/specs/source-date-epoch/)
> The value MUST be reproducible (deterministic) across different executions of the build, depending only on the source code. **It SHOULD be set to the last modification time of the source, incorporating any packaging-specific modifications.**

# Potential solution
One idea to accomplish this by allowing source plugins to implement a function that gets the last modification time of their fetched source. `git`-based plugins could use the commit timestamp, `tar` could use the modification date of the fetched file, etc.

BuildStream would then consult with each source plugin in a given element, and dynamically push the latest source date from each of the source plugins into the `%{source-date-epoch}` variable. So when source plugins are present in an element, the `%{source-date-epoch}` variable would essentially be dynamically updated (similarly to `%{max-jobs}`) to the actual source date. Otherwise, if no source plugins are present, the source date would remain with the sane default of 2011-11-11 11:11:11 UTC.

Projects defining their `$SOURCE_DATE_EPOCH` environment variable according to the `%{source-date-epoch}` variable would then become compliant with the spec, assuming the source plugins they rely upon actually provide a souce date.

This function can be made optional to plugins, and only "nice" plugins would implement it and provide a source date. This also be done in bst-1, but using a new variable (not `%{source-date-epoch}`), to avoid affecting the cache key.

It can also be made mandatory (but only in bst master), and plugins that don't have a way to provide the source date could return NULL to indicate this.

The issue names no files, tests, or entry points. Start by tracing the source-date-epoch variable and source plugin interfaces, then determine how fetched-source dates should be combined and how the bst-1 cache-key constraint applies. Done means the behavior follows the reproducible-builds specification while retaining the stated default when no source date is available.

Written by the indexing model from the issue text.