feat(ws): Define k8s workload manifest for backend component #324

[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?

[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 thesuperzapper 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:

• OWNERS

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

[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)