Optional chaining in import bombs plugin out

Given the following config (which is used as part of a larger shareable config that gets published to npm):
```js
module.exports = {
plugins: ['import'],
settings: {
'import/parsers': {
espree: ['.js', '.jsx'],
},
},
rules: {
// static analysis
'import/no-unresolved': 0,
'import/named': 2,
'import/default': 2,
'import/namespace': 2,
'import/no-restricted-paths': 0,
'import/no-absolute-path': 2,
'import/no-dynamic-require': 0,
'import/no-internal-modules': 0,
'import/no-webpack-loader-syntax': 2,
'import/no-self-import': 2,
'import/no-cycle': 0,
'import/no-useless-path-segments': 2,
'import/no-relative-parent-imports': 0,
// helpful warnings
'import/export': 2,
'import/no-named-as-default': 2,
'import/no-named-as-default-member': 2,
'import/no-deprecated': 2,
'import/no-extraneous-dependencies': 0,
'import/no-mutable-exports': 2,
'import/no-unused-modules': 2,
// module systems
'import/unambiguous': 0,
'import/no-commonjs': 0,
'import/no-amd': 2,
'import/no-nodejs-modules': 0,
// style guide
'import/first': 2,
'import/exports-last': 0,
'import/no-duplicates': 2,
'import/no-namespace': 0,
'import/extensions': [
2,
{
jpg: 'always',
jpeg: 'always',
js: 'never',
json: 'always',
png: 'always',
scss: 'always',
svg: 'always',
webp: 'always',
},
],
'import/order': [
2,
{
groups: [
'builtin',
'external',
'internal',
'parent',
'sibling',
'index',
'unknown',
],
'newlines-between': 'never',
},
],
'import/newline-after-import': 2,
'import/prefer-default-export': 0,
'import/max-dependencies': 0,
'import/no-unassigned-import': 0,
'import/no-named-default': 2,
'import/no-default-export': 0,
'import/no-named-export': 0,
'import/no-anonymous-default-export': 0,
'import/group-exports': 0,
},
};
```

When *stuff-utils.js* is imported into *Foo.js* (see internals below), you get multiple errors from seemingly unrelated rules.

*Foo.js*
```js
import StuffUtils from './stuff-utils';

const Foo = () => {
const onButtonClick = evt => {
StuffUtils.doStuff();
};

return (

);
};

export default Foo;
```

*stuff-utils.js*
```js
const StuffUtils = {
doStuff(foo) {
const bar = foo?.bar || 'bar';

return bar;
},
};

export default StuffUtils;
```

Reported errors:
```
/Users/mprzybylski/Work/fe-eslint-config/examples/Foo.js
1:24 error Parse errors in imported module './stuff-utils': Unexpected token . (3:25) import/namespace
1:24 error Parse errors in imported module './stuff-utils': Unexpected token . (3:25) import/no-deprecated
1:24 error Parse errors in imported module './stuff-utils': Unexpected token . (3:25) import/default
1:24 error Parse errors in imported module './stuff-utils': Unexpected token . (3:25) import/no-named-as-default
1:24 error Parse errors in imported module './stuff-utils': Unexpected token . (3:25) import/no-named-as-default-member
```

Changing *stuff-utils.js* to the below, no errors are reported in the same setup/configuration:
```js
const StuffUtils = {
doStuff(foo) {
const bar = foo.bar || 'bar';

return bar;
},
};

export default StuffUtils;
```

Reproduce the reported configuration with Foo.js importing stuff-utils.js, first comparing the optional-chaining example with the foo.bar variant. Trace how the imported module is parsed and how the affected import rules report that parse failure. Done means the optional-chaining module no longer produces the listed unrelated rule errors under the shown setup.

Written by the indexing model from the issue text.