Distinguishing between data errors and user abort

[marcoscaceres]

The spec says:

Activate the chosen share target, convert data to a format suitable for ingestion into the target, and transmit the converted data to the target. If an error occurs starting the target or transmitting the data, reject p with an "AbortError" DOMException, and abort these steps.

We probably want a DataError error here, so a developer knows that it's not the user aborting, but something wrong with the data they are trying to pass.

[ewilligers]

If they pass types that don't match the IDL, the bindings layer will generate a type error.
If they pass a bad URL, or don't pass any of the members that the implementation recognizes (currently title, text, url, optionally files), the implementation generates a type error.

If they are passing more data than the implementation allows (e.g. too many files, or files too large, or forbidden MIME types or file extensions), the implementation might generate a NotAllowedError.

I don't see see other failures as being due to the user data.

[marcoscaceres]

NotAllowedError seems good... I'll updated #113

[marcoscaceres]

Oh wait... NotAllowedError could be confused with "not triggered by user activation". Still unclear to me (with developer hat on 🤠) that my data was no good... even if it was valid at the WebIDL binding layer.