FE Development: Introduce new Dashboard Page

# Background

The final designs are here, including full prototype and responsive variations: https://www.figma.com/file/w458eXFjDWdJVrablD8aBs/Dashboard?type=design&node-id=0%3A1&mode=design&t=kw5S7naTPF8KTIwF-1

To understand the context of the design, please read this issue: https://github.com/Joystream/joystream-org/issues/650

# Task Requirements

- You must use existing tech stack (SCSS, Node, React and Gatsby), no new front-end frameworks for components, styling, animation, routing or any other major application architecture can be introduced.
- Work must be done in one ongoing PR, subject to review from both front-end engineer reviewer and designer.
- Must be tested in all major browsers and screen dimensions before review begins.
- Collaboration happens in our community Discord, and you must be available there for discussion and giving updates on progress.

# Proposal

- Implement a new page on route `/dashboard`
- Add new menu item called `Dashboard` that loads this page
- Follow designs provided above, implement animations, interactions, responsiveness _exactly_ as specified, this will be reviewed by a designer before delivery.
- The backend API is not yet complete, so for now just use mock data, **BUT** separate data from presentation itself, so that changing what is displayed does not require messing around with any presentation code (html, css, react, etc.). This is very important in particular because parts of the data on this page will be static, but not yet specified in terms of concrete values.
- The video in the design header is the same as on the main landing page: www.joystream.org

# Steps

1. Dev reviews task requirements, design, site code base, and asks any clarifying questions needed.
2. Dev proposes a plan for executing on proposal in the following stages, where the proposal must provide an explicit, estimate in terms of hours of work **including time for feedback and making changes**, and also in terms of how many days it will take for the dev to be able to clock that many hours, if work is not full time. Each stage must be completed in fully responsive variation and all interactions and animations. The stages are
a) Basic empty page + menu
b) Hero section
c) Token section: notice the hover interaction on the charts and tooltips, look at user stories page on Figma
d) Backers section
e) History section: notice the dialog window on click
f) Traction section
g) Engineering section
h) Community section
i) Team section
j) Community section
k) Comparison section
l) Roadmap section: data should be read from same place where the roadmap data already lives on the site.
If this sort of plan is not advisable, the dev should raise this point and suggest an alternative execution plan.
3. Product owners (me) approves plan, and work begins.
4. Dev executes on each stage, all in one PR, but requests a review after each stage is completed, with a summary of time consumed, problems faced, workarounds and questions. This does not mean that questions cannot be asked on Discord before that time.
5. Feedback is provided on the stage, which is incorporated, before work on next stage begins.