Modernize lock acquisition to RAII

We could gain a few things from moving the lock framework to a class:

* It would allow using more than one lock backend on the same site. This might be useful if you wanted to use a different class to prevent stampedes vs. race conditions.

* We'd be able to apply the (not yet committed) patterns in #1164484: Cache backend consistency runtime check and graceful downgrade mecanism → for graceful fallback and #1167144: Make cache backends responsible for their own storage → to remove dependencies on system module.

* Currently whenever we change bootstrap order or add or remove locking to a low level bootstrap function, we have to move the require_once lock.inc and lock_initialize() code around

* Having an interface enforces that backends comply to the API.

* If we want to write unit tests for systems that depend on the lock framework, this would make it possible to mock the lock API.

Attaching a first go at this, makes the following changes:

- adds a Lock interface and LockDatabase default implementation to lock.inc

- instead of bootstrapping the lock system, bootstrap.inc just includes a factory function lock() - this handles loading the code and instantiates the class (defined in variables) into a static cache. This means there is no more need to explicitly load the code and initialize the framework - this should be a small memory/cpu saving on every request that doesn't try to acquire locks (nearly all of them).

- the external API for calling code changes from lock_acquire(), lock_wait() etc. to lock()->acquire(), lock()->wait(). That's it.

- instead of registering a shutdown function for releasing locks at the end of the request, it uses __destruct().

Ran lock tests locally but no others.