Autolinking should error if modules are misconfigured, rather than ignoring them

Summary

Autolinking should throw an error if a native module claims to support windows autolinking but then provides an invalid configuration, making autolinking not possible.

There should also be a CLI flag to use the previous behavior of just logging.

Motivation

Right now, if autolinking detects that a native module dependency is misconfigured, it simply skips it and reports to the verbose logging, rather than failing the build.

Having it error out would alert the dev that a module isn't going to autolink as expected.

Basic Example

Rather than simply logging that the dependency was invalid, throw a CodedError.

However, this change in behavior would potentially break builds that were passing before. I.e. a module may have a working ios/android implementation, and for one reason or another, a broken windows implementation. So the app chooses to simply not use that module on Windows in their app code, and has been relying on autolinking to ignore the broken module.

So we'll also want to add some kind of CLI flag to let users revert to the previous behavior, and ignore invalid dependencies.

Open Questions

No response

Start by locating the Windows native-module autolinking validation and the CLI option handling described in the issue. Confirm how invalid configurations are currently logged, then define the error and opt-out behavior and add coverage showing both the default failure and the legacy ignore mode.