Include `script-sample' for "eval" violations

[arturjanc]

In #119 we talked about including a script-sample for "inline" violations to help developers identify the markup that caused the violation (or determine that the violation is a false positive caused by an extension).

@lweichselbaum suggested that it would similarly make sense to include the string argument to an eval-like function if the blocked-uri is "eval". For developers who adopt policies without 'unsafe-eval' this would help detect the sources of any eval()-related violations and give them confidence that the policy will not break the application.

This is less pressing than the work in #119 but seems consistent with the spirit of the script-sample field. In the future it could help developers get rid of 'unsafe-eval' to reduce the possibility of eval()-based DOM gadgets allowing CSP bypasses.

[mikewest]

I think we chatted about this; my feeling at the time was that eval() was more rather than less likely to contain PII. shrug If we're making the whole thing opt-in, then I suppose there's not a great deal of additional risk.

@dveditz, @mozfreddyb, @ckerschb, WDYT?

[lweichselbaum]

After issue #119 is closed, script-src violation reports caused by eval() are the only ones left that do not provide actionable information (same situation as with inline script violations before. It's usually not possible to differentiate between real violations and violations caused by extensions).
Any chance we could get the 'script-sample' field populated for these violations as well?