Part 1.5 of #16753

This PR removes the __DEV__ wrapping part of wrap-warning-with-env-check and replaces it with a functionally identical eslint plugin (no-production-logging).The babel rule gets renamed to lift-warning-conditional-argument because that's what it does! In its current stage this will fail builds since we still got all the unwrapped calls in the actual codebase.

The plugin supports &&statements like if( __DEV__ && React.suspenseIsEnabled) but fails any top level ||s. Have a look at the tests and code because I might have some unchecked assumptions about static code analysis here (and about how we strip out the __DEV__ checks at compile time lol) but i think this covers the cases we wanna cover.

Caveats

The generated development builds will include an extra block around the checks, from this original code

if(suspenseEnabled){
  warning(2===2, 'example warning');
  ...
}

eslint (in this branch) will make the editor rewrite it to

if(suspenseEnabled){
  if(__DEV__){
    warning(2===2, 'example warning');
  }
  ...
}

Which babel will transform (using ternaries) to

if(suspenseEnabled){
  if(__DEV__){
    2===2 ? warning(false, 'example warning') : void 0;
  }
  ...
}

And then rollup will rewrite __DEV__ to true (for a dev bundle)

if(suspenseEnabled){
  if(true){
    2===2 ? warning(false, 'example warning') : void 0;
  }
  ...
}

And finally, commonjs remove the useless if (this seems like a happy side effect rather than something we are doing on purpose for the dev builds - as for prod we run the closure compiler). However it will keep the block scope:

if(suspenseEnabled){
  {
    2===2 ? warning(false, 'example warning') : void 0;
  }
  ...
}

This makes sense to me, this block scope is pretty absurd but we can't remove blocks automatically (at least not naively) because in some cases it can affect the scope of variables.

We didn't have this before because babel would transform everything using ternaries, which don't start a block scope. Since we are moving the DEV check to the userland now I don't think we want people writing this manually:

if(suspenseEnabled){
    __DEV__ ? 2===2 ? warning(false, 'example warning') : void 0 : void 0;
  ...
}

Next steps

How do we merge this? The way I see it we can either

• Set the rule to warn, progressively fix the warnings. Don't like this because we don't have any rules set to warn? I might be wrong here? help??
• Prepare an eslint fix on this PR and apply it before merging. The builds will become green.