GULP (version 5.1)

Reworded, to emphasize that an indirect lock is not a separate lock,
to handle LOCKing an unmapped resource, and to handle locking live
properties.
************************** 
Grand Unified Lock Proposal (V5.1) 
- A lock either directly or indirectly locks a resource.
- A LOCK request creates a new lock, and the resource identified by
 the request-URL is directly locked by that lock. If at the time of
 the request, the request-URL is not mapped to a resource, a new
 resource with no content MUST be created by the request. The
 "lock-root" of the new lock is the request-URL.
- If a collection is directly locked by a depth:infinity lock, all
 members of that collection (other than the collection itself) are
 indirectly locked by that lock. In particular, if a binding to a
 resource is added to a collection that is locked by a depth:infinity
 lock, and if the resource is not locked by that lock, then the
 resource becomes indirectly locked by that lock. Conversely, if a
 resource is indirectly locked with a depth:infinity lock, and if the
 result of removing a binding to the resource is that the resource is
 no longer a member of the collection that is directly locked by that
 lock, then the resource is no longer locked by that lock.
- An UNLOCK request deletes the lock with the specified lock token.
 The request-URL of the request MUST identify a resource that 
 is either directly or indirectly locked by that lock.
 After a lock is deleted, no resource is locked by that lock.
- A lock token is "submitted" in a request when it appears in an If 
 header tagged-list whose tag is the lock-root of the lock. 
- If a request would modify the content for a locked resource, a dead
 property of a locked resource, a live property that is defined to be
 lockable for a locked resource, or a binding of a locked collection,
 the request MUST fail unless the lock-token for that lock is
 submitted in the request.
- If a request causes a directly locked resource to no longer be 
 mapped to the lock-root of that lock, then the request MUST 
 fail unless the lock-token for that lock is submitted in the 
 request. If the request succeeds, then that lock MUST have been 
 deleted by that request. 
- If a request would cause a resource to be locked by two different
 exclusive locks, the request MUST fail.
**************************