Summary:
This commit amends the comment added in #1601 per my subsequent
investigations. The generated SVG includes hash characters in the
`clip-path` attribute; Firefox interprets these as fragment specifiers,
truncating the SVG. The prior version of the comment speculated that the
issue was related to the length of the SVG, but there’s no evidence that
this is the case.

With this understanding, it’s easy to construct a [simple repro][1] to
confirm this behavior. In Firefox 61, a data-URI describing an SVG image
with a hash character is invalid in both an `img src` and an `a href`;
in Chrome 72, it’s fine in both. Firefox and Chrome also differ in their
handling of newlines in the non-encoded data-URI; Chrome includes the
newlines (except for the last one), while Firefox strips them.

[1]: https://gist.github.com/wchargin/f644d584ddafb19d003d46084c0f80e5

Test Plan:
No functional change. Inspect the above-linked gist to confirm behavior.

wchargin-branch: svg-url-truncation-comment

Summary:
This commit amends the comment added in #1601 per my subsequent
investigations. The generated SVG includes hash characters in the
`clip-path` attribute; Firefox interprets these as fragment specifiers,
truncating the SVG. The prior version of the comment speculated that the
issue was related to the length of the SVG, but there’s no evidence that
this is the case.

With this understanding, it’s easy to construct a [simple repro][1] to
confirm this behavior. In Firefox 61, a data-URI describing an SVG image
with a hash character is invalid in both an `img src` and an `a href`;
in Chrome pre-72, it’s fine in both, while Chrome 72 behaves the same as
Firefox. Firefox and Chrome also differ in their handling of newlines in
the non-encoded data-URI; Chrome includes the newlines (except for the
last one), while Firefox strips them.

[1]: https://gist.github.com/wchargin/f644d584ddafb19d003d46084c0f80e5

Test Plan:
No functional change. Inspect the above-linked gist to confirm behavior.

wchargin-branch: svg-url-truncation-comment

Data uri in the link for download has given us some trouble with
encoding and length limitations. We want to use the ObjectURL like
PR #1610 that is more durable to aforementioned limitations.

Related to #1601.