CS_LockNextConflict: Release locks in other buffers

Unlocking should not be necessary when using this function and the last
lock in another buffer is not always released explicitly.

Trigger an error and don't release the lock, if there is an attempt to
restore a locked conflict in another file.
Track the locked buffer

The buffer is needed to undo the buffer mappings.  Tracking the file for
the lock was totally wrong and this is the start of a fix for that.
Release the lock in the owning buffer

To release a lock in a buffer that is not the current one, switch to it
and execute the whole operation in the buffer with the lock.  To not
disturb any diff settings, operate in another tab and close it when
finished.

This fixes the unmapping errors when trying to release a lock from
another buffer.
Lock the buffer instead of the file

Change all the corresponding terminology from 'file' to 'buffer' and
rename affected functions.

Add an additional flag 'b' to CS_QueryState and its implementation that
does the same as 'f'.  Use 'b'.  Deprecate 'f'.

Error messages do now contain both, the buffer number and the basename
of the file.  If there is ambiguity, the full path can be obtained from
the conflict info display.
Add a missing dict attribute