General best-practices cleanup

[charles-dyfis-net]

Changes proposed in this pull request:

• Avoid calling jq more than once per operation. To do this, we have jq generate assignments with eval-safe escaping setting all required shell variables from a single invocation.
• Avoid passing anything but options through eval (keeping options themselves from being eval'd will be a compatibility-breaking change, and is the subject of cloud-gov/s3-resource-simple#50). The prior logic running eval aws s3 sync "s3://$bucket/$path" $dest $options gained none of the benefit from quotes around s3://$bucket/$path, because eval itself concatenated the literal arguments (with syntactic quotes discarded from the quote-removal parsing stage) into a single string before starting the parsing process over from the beginning; the new logic no longer uses eval for this entire command, but instead only uses eval when processing $options into "$@".
• Avoid using echo to handle non-constant data (which introduces substantial portability problems across different implementations of sh; see https://unix.stackexchange.com/a/65819/3113 and https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html). Also avoid echo $variable where $variable is unquoted, which can result in values being glob-expanded before being passed to echo, as well as transforming characters in IFS to spaces and collapsing runs of multiple such characters to a single instance per each.
• Handle "null" return value from aws s3api list-objects gratefully (fixes cloud-gov/s3-resource-simple#49)
• Quote "$0" inside "$(dirname "$0")"; the modern command substitution format used here introduces a new quoting context, so directory names with spaces (or an unexpected IFS value) could result dirname being passed an unexpected number of arguments with the old code.

Security considerations

Because we deliberately do not modify the behavior described in cloud-gov/s3-resource-simple#50, the preexisting opportunity for shell injection via $options remains intact. However, we do narrow the code to only be evaling $options, so it's no longer possible to perform shell injection via $bucket or $path.

In every other respect, this PR works to reduce runtime ambiguity, and thus to also reduce attack surface.

[charles-dyfis-net]

BTW, one thing that may be notable in the recently added commit (returning to a separate jq call per variable) is the change from echo to printf. For background on that, see the excellent answer by Stéphane Chazelas on Why is printf better than echo?, or the APPLICATION USAGE and RATIONALE sections of the POSIX standard for echo.

If we were specifying a specific shell (like bash), making assumptions about echo behavior would be slightly justifiable (though only slightly: even with bash, configuration parameters like xpg_echo modifying behaviors in the cases the standard describes as ambiguous can be set at compile time, or via environment variables at runtime, or via explicit runtime commands); but if we're using /bin/sh, best to avoid cases the POSIX sh standard describes as ambiguous altogether.

[markdboyd]

Approved. Thanks @charles-dyfis-net for the contribution!