Update: no-void add an option to allow void as a statement

[bradzacher]

What is the purpose of this pull request?
Changes an existing rule

What rule do you want to change?
no-void

Does this change cause the rule to produce more or fewer warnings?
Fewer, when the option is turned on

How will the change be implemented? (New option, new default behavior, etc.)?
New option

Please provide some example code that this change will affect:
Code that will now be valid, when the option is turned on:

/*eslint no-void: ["error", { "allowAsStatement": true }]*/

void foo;
void someFunction();

What does the rule currently do for this code?
Errors for all void operator usage, regardless of context

What will the rule do after it's changed?
When the option is on, it will allow the void when used as a statement.

Why?
A common usage pattern I've seen out in the world is to use the void operator to mark promises as "consumed" without awaiting them.
I.e. it's a way for users to say "I am intentionally not awaiting this promise".

async function returnsPromise(): Promise<void> {}

void returnsPromise();

This pattern works well with our rule @typescript-eslint/no-floating-promises, which would otherwise error on the above promise if the void operator was omitted.

Feel free to push back, we could potentially extend this rule within @typescript-eslint, and make it type aware to only allow it for thenable values, but I thought I'd see if you guys thought there was value in this before forking.

[kaicataldo]

Sorry for the delay! I'm supportive of this change and will champion it. We just need one more 👍 from the team to mark it as accepted.

[mdjermanovic]

It would be nice to have a test with an empty options object, to ensure that the default value in schema is false. Maybe also one with the option explicitly set to false.

Semi-related, it's interesting that no-unused-expressions already allows 'void statements', so there will be no problems with this.

[mdjermanovic]

LGTM, thanks!

[kaicataldo]

Thanks for contributing!