…n using `extractCss` and `@import` rule

Relevant code:
https://github.com/webpack-contrib/css-loader/blob/239e43d1f3c88bce9433e49b9674be2192a118bb/src/plugins/postcss-import-parser.js#L9

https://github.com/webpack-contrib/css-loader/blob/239e43d1f3c88bce9433e49b9674be2192a118bb/src/index.js#L132-L150

Fixes #9475

When Ivy is enabled in an app, the app's dependencies are processed by
ngcc (the Angular compatibility compiler), which will generate new
Ivy-compatible entry-points in each package. To allow webpack find those
entry-points, it will add references to them in `package.json`, named
after the original property with the `_ivy_ngcc` suffix. So, for
example, `es2015` and `module` will become `es2015_ivy_ngcc` and
`module_ivy_ngcc`.

Previously, the `mainFields` passed to webpack would give higher
priority to an Ivy entry-point compared to the corresponding non-ivy
entry-point but not compared to other entry-points. For example,
`es2015, module` would becode
`es2015_ivy_ngcc, es2015, module_ivy_ngcc, module`. This could mean that
`es2015` would be preferred over `module_ivy_ngcc`, even though the
former is probably not Ivy-ready. Generally, if `es2015` exists and has
a higher priority than `module`, then `es2015_ivy_ngcc` would be
generated before (or instead of) `module_ivy_ngcc`, but this can be
changed using an ngcc configuration file (`ngcc.config.js`).

This commit fixes this by ensuring that any `_ivy_ngcc` entry-point is
considered before any of the original entry-points in the `mainFields`
list.

NOTE:
While it is possible that a format is Ivy-compatible without bhaving an
`_ivy_ngcc` suffix (e.g. if the user does a manual ngcc pass without
`--create-ivy-entry-points`), it is quite unlikely to happen and even if
it does, choosing a different format should be OK.

(cherry picked from commit c7c574a)

This seems to be the root cause of the failures in the following PR:
#17455

(cherry picked from commit a78fe96)

…sions

(cherry picked from commit 1f16002)