Merge content_lock_timeout into content_lock

Problem/Motivation

For many years people have wanted the ability to release a lock when you navigate away from a content edit screen but with issues like #2949202: Previewing appears to unlock node this is going to be extremely complex to offer.

After a long discussion with @chr.fritsch and @daniel.bosen we've decided to make functionality provided by content_lock_timeout part of the default experience. This will make it less likely that content is locked when a user edits a node and we can also check the timeout when determining with content is locked.

Proposed resolution

Deprecate the content_lock_timeout module and move all the functionality and configuration into content_lock

Remaining tasks

User interface changes

New timeout settings on the Content Lock settings form.

API changes

ContentLockInterface::fetchLock() has a new bool $include_stale_locks argument that defaults to FALSE. The default behaviour is such this method will not return stale locks.

ContentLockInterface::locking() will release stale locks when locking content.

Data model changes

content_lock.settings has a new key timeout that determines the default timeout for a content lock. The initial value is 1800 - ie. 1 hour. Existing sites that did not have content lock timeout installed will be set to NULL and there will be no timeout. Sites which had content_lock_timeout installed will have their existing content_lock_timeout setting migrated.