Clarify specifications about replication / forcing timestamps in records

In the docs, we can read:

> «If [the specified timestamp] is in the past, the record is created with the timestamp in the past but the list timestamp is bumped into the future as usual.» [source](https://github.com/Kinto/kinto/blob/1179dbb/docs/api/1.x/timestamps.rst)

While trying to fix #1357 I realize I wasn't able to remove the bottleneck and obtain this behaviour. Good news is that the behaviour specified in the tests suite are consistent with the docs.

But I can't recall how and why that makes sense (apparently @Natim either). It comes from https://github.com/mozilla-services/cliquet/pull/665 at the time @almet was working on kinto-signer replication.

Can we explain somewhere how the synchronization will work in that case? How will the client poll for changes and obtain the records in the past if we only bump the collection timestamp?

If we clarify this, there is a chance we can fix #1357 with something like in #1361

The tests are:
* `test_create_ignores_specified_last_modified_if_in_the_past` https://github.com/Kinto/kinto/blob/69af0eab99215975cea65e8d35738fe709d23761/kinto/core/storage/testing.py#L774-L793
* `test_update_ignores_specified_last_modified_if_in_the_past` https://github.com/Kinto/kinto/blob/69af0eab99215975cea65e8d35738fe709d23761/kinto/core/storage/testing.py#L837-L855

Read docs/api/1.x/timestamps.rst and the linked replication discussion first, then inspect the named tests in kinto/core/storage/testing.py. Clarify how clients discover records whose specified timestamps are in the past while the collection timestamp is bumped, and document the behavior consistently with the tests.

Written by the indexing model from the issue text.