build: Use buildpacks for better caching

[MoritzWeber0]

Advantages of buildpacks against the current approach with Dockerfiles:

• Exchange individual layers. This enables:
  • Update the dependencies without update of the Capella layer
  • Update TeamForCapella archive without update of the Capella layer
  • Update dropins independently
• Reduction of the image sizes = faster image pull times = faster session startup in the Collaboration Manager.
  Examples:
  • capella/base:6.0.0: 3.5GB -> 1.5GB
  • t4c/client/base:6.0.0: 4.5GB -> 1.6GB
• Reuse layers of last builds, massively reducing storage space and network traffic in registries
• Less layers, the new layers are clearly mentioned and separated in different scopes (capella layer, capella-dropins layer, t4c-client layer, ...)
• Full reproducible builds (same input = same digest of output images)
• No extensive build cache which sums up in local development (instead, it uses layers of the last image as cache)

This PR is a full rewrite of the Dockerfile instructions - getting rid of many instructions which are not needed anymore or were defined multiple times.

I could also get rid of the "Instance data location not specified" errors by providing a workspace to the P2 commands.

Some features are removed!

• Installation of older libwebkitgtk versions, wasn't functional anymore.
• Injection of own debian packages, wasn't actively used as of my knowledge.

TODO:

• Update the GitHub Actions template
• Update GitLab CI template (consider volume mount)
• Update Makefile
• Clear workspace directory
• Manual testing
• Migrate the remote image to buildpack
• Add builders for juypter, eclipse and pure::variants
• Optional: Clean old images from registries
• Run startup scripts also on entrypoint of capella & t4c images
• Install T4C CLI in TeamForCapella image
• Use exec.d for runtime configuration
• Update docs
• Change base image to buildpack extension
• Getting Started for Developer (checklist in docs), should contain: Getting started buildpacks, extensions, exec.d + env variables. Also fastAPI + Angular
• Explore options for non-root builds in a cluster

Resolves #289