standardize & centralize path validation and coercion

[ClaytonJY]

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.