Modify the reporting feature policy to enable/disable the entire API

[johnivdel]

Currently, this explainer proposes using a feature policy to enable/disable reporting for specific third parties in cross origin contexts (https://github.com/csharrison/conversion-measurement-api#permission-delegation).

To simplify this mechanism, we could instead gate the entire conversion measurement API behind a feature policy, with reporting to third parties explicitly allowed. The feature could be allowed in the top level context by default, but not in cross-origin children. Without the feature allowed, a cross origin child would not be able to declare an impression anchor tag.

This is more inline with the purpose of feature policy and better classifies as a powerful feature per w3c/webappsec-permissions-policy#252, a concern raised on #1 .

A top level browsing context and cooperating iframe could recreate the API functionality by postMessaging impression data, reporting domain, and ad destination to the top level context who can then wrap the iframe in an anchor tag. With some additional complexities behind handling clicks on the iframe. Exposing this via feature policy simplifies this process.

If the top level page only partially trusts an iframe, they can still utilize this postMessage configuration to sanitize inputs or exercise other arbitrary controls over the impression declaration.

This also gives the publisher site the ability to disable the API for the entire page if they do not want to entrust 3P scripts in the top level context to use this API.

[johnivdel]

cc @clelland

[csharrison]

This simplification SGTM. It removes complexity and avoids depending on non-standard FP string parameterization.