Chore: Enable prefer-optional-chain ESLint rule for TypeScript files

[tassoevan]

Proposed changes (including videos or screenshots)

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted.
The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there's more stuff to move around.
Furthermore, more code often means less flexibility and functionality. This is counter-intuitive, but a lot of times a simple, elegant solution is faster and more general than the plodding mess of code produced by a programmer of lesser talent.
Code is produced by engineers. To make more code requires more engineers. Engineers have n^2 communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.
You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.

— Rich Skrenta

Mixing two problem domains in code is prone to errors. In this small example

declare const y: { z: unknown } | undefined;

const x = y && y.z;

we're (1) checking the nullity of y and (2) attributing y.z to x, where (2) is clearly the main problem we're solving with code. The optional chaining is a good technique to handle nullity as a mere implementation detail:

declare const y: { z: unknown } | undefined;

const x = y?.z;

Attributing y.z to x is more easily readable than the nullity check of y.

This PR aims to add @typescript-eslint/prefer-optional-chain rule to ESlint configuration at warning level.

Issue(s)

Steps to test or reproduce

Further comments

[CLAassistant]

All committers have signed the CLA.