[website] Add components index page

[siriwatknp]

Preview: https://deploy-preview-28485--material-ui.netlify.app/components/

This page is essential for setting page_rank of all components to appear first in docsearch. According to #28333

• For the design, I make it similar to Navigation drawer but with our Masonry component! (I think we can go with this simple design at first to unblock the docsearch improvement because it can only be access directly from the url and later improve with fancy design)
• Same pages data as in navigation

---

• I have followed (at least) the PR section of the contributing guide.

[mui-pr-bot]

No bundle size changes

Generated by 🚫 dangerJS against 213580f

[eps1lon]

Can we render something simpler? This page isn't that important right now to look perfect. But looking broken is worse:

1. double scrollbar
2. overlapping items
   

[siriwatknp]

looking broken is worse

Oh no, it was working in my machine. I will remove Masonry and use simple grid instead.

[eps1lon]

looking broken is worse

Oh no, it was working in my machine. I will remove Masonry and use simple grid instead.

Would be nice to track this in a separate issue for the Masonry with a codesandbox.

[danilo-leal]

Good for now! Excited to revamp this one later on :)

[oliviertassinari]

This link self-reference itself.

[oliviertassinari]

Oh no, it was working in my machine. I will remove Masonry and use simple grid instead.

cc @hbjORbj

[siriwatknp]

This link self-reference itself.

Good catch, there are children in the menus. Fixed!

[hbjORbj]

Can we render something simpler? This page isn't that important right now to look perfect. But looking broken is worse:

1. double scrollbar
2. overlapping items
   

I think this comes from the known limitation of current masonry implementation (issue: #27934)
As a result of this limitation, a scrollbar appears in masonry, and items at the bottom start to get squashed if masonry's height goes beyond 2,000px. This is obviously a very serious limitation, and it's the main reason to go for the flexbox approach (PR: #28059)...