Move jupyter-apis (frontend) into StatCan/kubeflow jupyter-web-app

[saffaalvi]

In order to start pushing our new features (in both centraldashboard and jupyter-apis) upstream, we need to bring our jupyter-apis changes back into the kubeflow repo. Upstream has both jupyter-web-app and crud-web-apps/jupyter so will likely have to update both of those with our jupyter-apis changes.

Our backend in jupyter-apis uses Golang while upstream uses Python. To make ours compatible with theirs when we push upstream, we should put the Go backend as a folder in stc-master for now.

[saffaalvi]

After merging jupyter-apis into the jupyter-web-app, we have decided this is not the best method to push our features upstream.

From the first attempt at merging using git merge --allow-unrelated-histories, the contents of jupyter-apis were merged into the main directory in StatCan/kubeflow. When moving the files back into components/jupyter-web-app, this caused the files to lose all their commit history. For reference, the branch with this method can be found here: https://github.com/StatCan/kubeflow/tree/merge-jupyter-apis

The second attempt at merging started off the same way as the first, with git merge --allow-unrelated-histories, but to move the files back into jupyter-web-app, git filter-repo --path-rename <old-filename>:<new-file-name> --force was used to keep the file history. However, this caused all the associated commits to be re-written and we would have to push all those commits (over 2000) back upstream. For reference, the branch with this method can be found here: https://github.com/StatCan/kubeflow/tree/merge-jupyter-apis-2

Instead, we will start manually adding in our new features to keep a cleaner and more understandable history as well as easier tracking for the features.