feat!: add read-only mode, fix XDG behavior in get_data_dir()

[jsstevenson]

• add read-only mode to get_data_dir(), either with a function arg readonly=True or env var WAGS_TAILS_READONLY=true. If True, don't try to mkdir(), but otherwise run some broad checks to confirm that it's actually writeable (raise an error if they fail). This begins to address Wags-tails incorrectly reads config files on containers #78
• Make the writeable error more explicit about params and refer back to the docs for easier debugging. Addresses Add note about XDG_DATA_HOME biocommons/anyvar#244
• clean up XDG data dirs behavior (XDG_DATA_DIRS should be read-only -- if one of the items already includes a directory named wags_tails, use it, but skip otherwise)
• make tests more granular, add a few

"read only mode" here is not truly read-only, because we will also need to force all source .get_latest() calls to use from_local=True. Unfortunately, we don't have a terribly elegant way of changing things on that side, so I'd prefer to see if this is good enough for now: if WAGS_TAILS_READONLY=true is declared in an environment where the required data is already available at an expected location, then I would expect no further writes to happen. I think I may tackle a bigger redesign effort during an upcoming bikeshedding week.

[theferrit32]

Is this extra criteria needed? Only if read-only is enabled, and only if the subdirectory already exists?

[jsstevenson]

Yeah, I've been chasing my tail on this a bit. When read-only is on, a nonexistent directory is useless, but I think it begs the question of what to do when $WAGS_TAILS_READONLY=true and $WAGS_TAILS_DIR is defined but doesn't exist. I guess a simpler way forward would be to not skip and fail once the process tries to write a file to the data subdirectory, because presumably if you can define $WAGS_TAILS_READONLY then you can also be smart enough to point $WAGS_TAILS_DIR to a real directory.