Part of #924

[oboha55]

Part of #924

Goal

To reduce the amount of imports from file that should be moved to the x-data-grid package to files that should be moved to the x-data-grid-pro package.

New behavior

Interface based on the package

If you import GridApi, GridState or GridInitialState from @mui/x-data-grid, you will have the community version.
If you import GridApi, GridState or GridInitialState from @mui/x-data-grid-pro, you will have the pro version.

Internally we use GridApiPro and GridApiCommunity while waiting for the bundle split.
Afterwards, we should be able to simplify things.

For all the interfaces depending on the api (for instance GridRenderCellParams to type its api param or GridColDef to type its renderCell params through GridRenderCellParams), I added an Api generic which extends GridApiCommon.
When exported from @mui/x-data-grid, the default generic value is the community api, when exported from @mui/x-data-grid-pro, the default generic value is the pro api.

Untyped interfaces

Some use case were to complicated to cover for now.
For instance, the columns prop of DataGrid has the type GridColumns. Otherwise, you could have errors when passing pro columns to the community version because TypeScript consider that the pro and community api are not compatible.

createSelector

The method now ask as a parameter the largest state used in one of its sub-selectors.

For instance the following selector will ask for GridApiPro because gridRowGroupingModelSelector is a pro selector.

const mySelector = createSelector(gridPageSizeSelector, gridRowGroupingModelSelector, () => null)

Note: Everything still works with the apiRef, I just simplified the typing to accept a ref which extends { instanceId: number, state: S }

What's next ?

In v6 we should drop all the api parameter to reduce as much as possible the scope of the plan-based typing.
This requires to open the apiRef to the community plan (which should be fairly easy after this PR).

Originally posted by @flaviendelangle in mui/mui-x#3648