Categorizing guides, plugins, loaders, etc.

There're so many guides, plugins and loaders listed in the sidebar now, and it's sort of overwhelming for users, especially new users of webpack.

One thing I've been thinking about is that we can categorize them like what we have done with the API page:

It's just a small change, but it would improve user experience a lot. Also there's already a group option we can use in the frontmatter, so that change won't be difficult.

Problem to solve

If we all agree the aforementioned change is necessary, now we have a problem to solve: How many groups should we have, and which page belongs to which group?

Loaders

It should be easy to handle loaders as there're already groups in its index page https://webpack.js.org/loaders/:

We can reuse them or even make changes when necessary.

Plugins

We might not be able to categorize plugins just like what we did to loaders, here's my proposal, we can use three groups to categorize them:

1. webpack: plugins defined under webpack namespace
2. webpack-contrib: plugins developed under webpack-contrib
3. others: other webpack plugins

Guides

This would be the most difficult part, but I think it's possible.

As there're too many potential topics under guides, we might categorize them based on the users' level of webpack, for example:

1. Quick start for webpack beginners
2. Intermediate
3. Advanced topics like https://webpack.js.org/guides/package-exports/ which common users won't care
4. Any other suggestion?

Cons?

No permalink would be changed because of the aforementioned change, we just upgrade the sidebar, so I believe there's no cons. But do let me know if you think there're.

Start with the documentation sidebar, the API page's existing grouping, and the loaders, plugins, and guides index pages mentioned in the issue. Review the available frontmatter group option and propose categories and page assignments before making changes. Done means the groups are agreed and the sidebar presents these pages in a less overwhelming structure without changing permalinks.