build: support ESM projects

[IlCallo]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Documentation
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• It's submitted to the dev branch and not the master branch
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• It's been tested on a Cordova (iOS, Android) app
• It's been tested on a Electron app
• Any necessary documentation has been added or updated in the docs (for faster update click on "Suggest an edit on GitHub" at bottom of page) or explained in the PR's description.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
No docs explaining how to take advantage of this yet.
In short:

• add type: "module" to your package.json
• change the extension of these files to .cjs: quasar.conf.js, .postcssrc.js, babel.conf.js, .eslintrc.js (optional) and jest.config.js (optional)

Some projects would need to delete their yarn.lock to force-update babel dependencies to use version >=7.7.0 (previous versions doesn't support .cjs config file).
Updating @quasar/babel-preset-app would solve the problem.

I dunno if it could be useful for #5893
I actually did it for a project of mine for which I was forced to enable native ES modules due to some constraints, I didn't checked if it could solve that issue too

[yusufkandemir]

I think we can make use of mlly, leaving it here for future reference: https://github.com/unjs/mlly

[therealcoder1337]

as requested in the discord, i will post my own experience with esm migration of non-quasar projects here.
this is what i use to load json files:

import {readFile} from 'fs/promises';

async function importJson (relativePath, importMetaUrl) {
    if (!importMetaUrl) {
        throw new Error('missing importMetaUrl');
    }

    return JSON.parse(await readFile(new URL(relativePath, importMetaUrl), 'utf8'));
}

export {importJson}

for my projects, i replaced occurrences of __dirname or relative paths with new URL(relativePath, import.meta.url). the URL constructor will resolve relativePath to the second parameter, which in this case is the url to the file (import.meta.url).
paths (urls) to folders can be a bit tricky, as i sometimes found them to require a trailing /:

const url = new URL('./to/path/', import.meta.url);
const url2 = new URL('../other/', url);
// url2 will miss the "to" dir, if you remove the trailing slash from "path/" of url

on the upside, most node fs functions seem to support instances of URL, which are the easiest to use if your aim is cross platform compatibility. at least we had some issues with using file:// based strings, but maybe we didn't use them correctly, since they have some complex rules: https://en.wikipedia.org/wiki/File_URI_scheme#How_many_slashes?
therefore, URL was the easier choice.

[yusufkandemir]

@quasar/app-webpack v4 and @quasar/app-vite v2 will support this. It's not been released yet, but it's been implemented. So, I am closing this PR.