Monorepo with yarn workspaces and lerna

[onursumer]

• Enabled yarn workspaces for package management -- needed to update the yarn to the latest version for this.
• Using lerna for multi package tasks (test, build, publish, etc.)
• Moved src/public-lib contents under packages/cbioportal-frontend-commons with a proper package.json and updated references accordingly -- this increases the number of files changed dramatically, but majority of these changes are just reference updates.
• Using shared rollup and ts config options to bundle modules under packages.
• Added github workflow to auto publish public packages to npm.

Checks

• Has tests or has a separate issue that describes the types of test that should be created. If no test is included it should explicitly be mentioned in the PR why there is no test.
• The commit log is comprehensible. It follows 7 rules of great commit messages. For most PRs a single commit should suffice, in some cases multiple topical commits can be useful. During review it is ok to see tiny commits (e.g. Fix reviewer comments), but right before the code gets merged to master or rc branch, any such commits should be squashed since they are useless to the other developers. Definitely avoid merge commits, use rebase instead.
• Is this PR adding logic based on one or more clinical attributes? If yes, please make sure validation for this attribute is also present in the data validation / data loading layers (in backend repo) and documented in File-Formats Clinical data section!

[inodb]

@onursumer Nice work! Just wanted to share I found something describing lerna and yarn workspaces. Maybe of interest: https://doppelmutzi.github.io/monorepo-lerna-yarn-workspaces/. Lerna seems more powerful for publishing individual packages but yarn workspaces allows skipping the bootstrap step. You can use both as well

When we introduce lerna, we prolly need some docs on how to install packages. Like how to install a dependency for one of the projects vs a dependency for all of them. As well as how to run the individual projects

[onursumer]

currently, jitpack is the only use case where we don't need to set env vars, so we call buildAll instead of build there.

[inodb]

LGTM