Strict CSP-compatibility: replace javascript: URIs with event handlers

[enricocarraro]

Description of Changes:

• Refactor of javascript: URIs generated by buildvolume in src/js/features/volume.js to enable strict CSP-compatibility.

Why:
Content Security Policy is a mechanism designed to make applications more secure against common web vulnerabilities, particularly cross-site scripting. It is enabled by setting the Content-Security-Policy HTTP response header.
An application can add a critical defense-in-depth layer against markup injection attacks by adopting a strict policy that prevents the loading of untrusted scripts or plugins.
To make an application compatible with strict CSP, it is necessary to make changes to HTML templates and client-side code and add the policy header:

1. Add nonces to <script> elements;
2. Refactor inline event handlers and javascript: URIs;
3. Refactor calls to JS APIs incompatible with CSP;
4. Serve the Content-Security-Policy header.

More on CSP.

This PR is related to a series of efforts to make WordPress strict CSP compatible, more on that here.

[coveralls]

Coverage remained the same at 74.376% when pulling 16a421e on enricocarraro:move_javascript_URIs into d8a667f on mediaelement:master.

[jaapmarcus]

This PR is also related to #2729

How ever "there" are some checks need to made if any "scripts" could cause issues..

[enricocarraro]

@jaapmarcus I didn't find any other incompatibilities that could break default behavior with strict CSP enabled without the 'unsafe-inline' option. The library doesn't generate any HTML that includes inline event handlers, doesn't use JS APIs incompatible with CSP, and doesn't write <script> tags.
Being more practical, a policy like this could work just fine when this PR gets merged:

Content-Security-Policy:
  script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;