docs(dashboard): updated centraldashboard-angular developer guidance

[andyatmiami]

Updates centraldashboard-angular README.md for better guidance following the split into kubeflow/dashboard from kubeflow/kubeflow.

Also adds a .gitignore entry for .angular - as following the local development guidance results in an .angular/cache directory we don't want in source control.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign orfeas-k for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• components/centraldashboard-angular/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[thesuperzapper]

@andyatmiami We need some way to guarantee the version of the kubeflow-common-lib which we are pulling from kubeflow/kubeflow, that is, which specific commit we are using.

However we do this, it needs to be used by both within the Dockerfile builds and local dev.

We could do one of the following:

1. OPTON 1a: what the katib UI does and create a COMMIT file which says which commit to build from
2. OPTON 1b: using the same COMMIT file, but downloading the repo .zip rather than invoking git itself
3. OPTION 2: with a git submodule

Either way, I hate the existence of this common lib, and I'm not entirely clear what value it provides.

[kimwnasptd]

Either way, I hate the existence of this common lib, and I'm not entirely clear what value it provides.

That it made it possible to maintain more than 5 different frontend web apps with same UX across :)

I'd propose to use the commit, as it'll require the least amount of changes. The library was meant to be a node module at some point to have the versioning made easier. But not worth investing any time on this now.