feat(ws): add manifests for backend

[liavweiss]

closes: #324

In this PR I have created the manifest workload for the backend component.
Added 2 targets to the Makefile deploy and undeploy.

How to deploy the backed component:

cd workspaces/backend
make docker-build
make docker-push
make deploy
kubectl port-forward svc/nbv2-backend 4000:4000 -n backend-system

How to undeploy the backed component:

cd workspaces/backend
make undeploy

@andyatmiami, regarding this PR, I want to consult with you:

1. I used type: NodePort in the service.yaml mainly because we dont have yet an nginx-ingress
   I can change it to be type: ClusterIP if needed
2. Im not sure about the image/container names, do you think we need to chnage it to be just a backend or we can leave it as it is nbv2-backend?

[andyatmiami]

see: https://github.com/kubeflow/notebooks/pull/455/files#r2195161112

[andyatmiami]

see: https://github.com/kubeflow/notebooks/pull/455/files#r2195161112

[andyatmiami]

w.r.t the "directory structure" for these files - I would propose the following:

	workspaces/
	├── backend/
		├── api/
		├── cmd/
		├── internal/
		├── manifests/
		│   ├── kustomize/
		│   │   ├── base/
		│   │   ├── overlays/			# (not needed - including as merely an example of future-proofing)
		│   │   │   ├── dev/
		│   │   │   ├── staging/
		│   │   │   └── prod/
		│   │   └── options/            # (not needed - including as merely an example of future-proofing)
		│   └── helm/                   # (not needed - including as merely an example of future-proofing)
		├── openapi/
		├── Dockerfile
		├── Makefile
		├── README.md
		├── ...

I feel this aligns more (loosely) with "industry standards" and/or expectations.

[andyatmiami]

refer to name of port (as outlined in https://github.com/kubeflow/notebooks/pull/455/files#r2195457108)

[liavweiss]

@andyatmiami, I have made all the changes, and the PR is ready for a final review.

[andyatmiami]

/lgtm

verified these changes with help of a script I have been working on to deploy Central Dashboard in kind ... can confirm backend component is successfully deployed and services frontend requests to perform supported behavior.

[andyatmiami]

/lgtm

re-verified the end-to-end of running kubeflow/notebooks frontend and backend components off the commit in this PR and confirmed traffic properly routed.

• https://github.com/andyatmiami/kubeflow-notebooks/blob/experimental/remote-deployment/workspaces/develop/scripts/setup-kubeflow-notebooks.sh

[andyatmiami]

/ok-to-test

[thesuperzapper]

Thanks @liavweiss and @andyatmiami, looks good to go for now.

Next step is automated e2e testing.

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: thesuperzapper

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [thesuperzapper]

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