We have more and more use cases that need major lifecycle signals produced by standard AMP element and extensions. We can implement each separately, but there are some issues:

1. Most of signals will not be used. Thus we want minimal CPU/memory until they are requested.
2. Most of life-cycle events can be split into two signals: start and end.
3. Individual code is a mess: it needs time, error, promise, resolver and rejector for all needs.

This PR:

1. Creates a minimally filled struct per signal and adds three methods to support it: whenSignal, signal and rejectSignal.
2. The initial set of signals demonstrated here is small, but extensions can supply their own. That's why these methods are public.
3. signal is the only "always use" method and thus it fills it only minimal parts of the struct and does minimal work. The rest is done lazily.
4. whenBuilt is an example of API-level usage. Some lifecycle signals can be easily exposed via special API. This is currently in work for another PR. (/cc @mkhatib Wait for amp-selector to build before submitting #7190)
5. signalDelta is an example of how many metrics can be calculated between two signals. This will be (already is) very common in many analytics needs.