standardize & centralize path validation and coercion

We currently have a utility function `add_slashes` that helps deal with the fact the Dropbox API generally expects a starting slash for path arguments, though this isn't always the case; the `list_folder` API errors on `path = "/"` but returns files in the root directory with `path = ""`.

There's also a whole bunch of regexing the API backend does, that we could consider doing ourselves to allow for more flexibility or more informative warnings; these are noted in the API docs. Also related to this is that some path-accepting fields allow paths like `"rev:..."` or `"id:..."` to fetch things by revision or id, instead of path. There might also be an `ns:...` judging by the regex in the API docs (`pattern="(/(.|[\r\n])*|id:.*)|(rev:[0-9a-f]{9,})|(ns:[0-9]+(/.*)?)"`), though I have no idea what that does yet.

Lots of ways we could handle this; probably ties into work for #109.