Potentially support platform-specific formats in BarcodeFormat enum

[jchinlee]

Currently, the specification provides "unknown" as a valid BarcodeFormat [1]. However, it doesn't make sense for a user to hint "unknown" in a BarcodeDetectorOptions, and returning "unknown" in getSupportedFormats doesn't (currently) make sense either.

One possibility proposed by @reillyeon is to convert "unknown" to "platform-specific", i.e. encompassing platform-supported formats unknown to the spec.

This could be passed back to the user, in getSupportedFormats or elsewhere, to indicate the platform supports more formats than expressed in the spec, and could be used by the user to include platform-specific formats in the hint in addition to spec-known formats.

[1] https://wicg.github.io/shape-detection-api/#dom-barcodeformat-unknown

[yell0wd0g]

I guess it all stems because BarcodeFormat is used both in getSupportedFormats() returned sequence and DetectedBarcode.format, where it makes sense to find an "unknown" but is also used in the settings dictionary BarcodeDetectorOptions, where it doesn't. Perhaps we could split it into two dictionaries, one with and one without the unknown.

[reillyeon]

My argument against "unknown" is also that it doesn't make sense that the API has detected an "unknown" barcode format because if the format is unknown then how was it detected? Even in the case of DetectedBarcode.format using "platform-specific" as the enum value would instead indicate simply that the format is one that is specific to the current native platform.