We ran in to an issue with various microsoft products accessing files
over WebDAV which contain `%` characters in the name. The requests are
all properly escaped -- e.g. the `%` is replaced with `%25`. Further
the basic list functionality of the propfind responses contain encoded
urls.

The lock response/discovery includes the URL (lockroot) to the locked
file. The existing implementation does not path escape that url. This
seems to cause problems with the microsoft applications. When faced with
the unencoded response, they try to lock again and fail. One explanation
for this behaviour is that they maintain a table of locks indexed by
encoded url. When the response from the server doesn't align with the
URL they locked, the application fails.

Update the lock discovery response code to escape the lockroot so that
it matches everything else.

The lockroot is a path in the webdav library, meaning it may have
slashes in it. Use the url.URL struct to handle this case when escaping
the lockroot. Also add some unit tests.