Injected app packages using squashfs and appimage

## Motivation

- Whenever code-server, jupyter notebook, etc. is updated or we want to add new “complex” applications to containers, we have to rebuild and redistribute the container images.
- Changing service-definition specification also requires rebuilding and redistribution of many container images, which is virtually impossible.
- There are known examples using [AppImage](https://appimage.org/) packaging: [NeoVim](https://github.com/neovim/neovim/releases).
- Known caveat: AppImage-based apps may crash after resuming from sleep (e.g., Linux VM running in macOS), due to some squashfs-related issues. (ref: [neovim#33465](https://github.com/neovim/neovim/issues/33465)) This wouldn’t be a problem in production setups where servers never sleep, but may be surprising for local dev setups on laptops.

## Objective

- Decouple the container application packaging from the container images.
- Allow container apps to be added or upgraded independently to the image lifecycles.

## Expected Sub Issue

- Test feasibility of the appimage-based packaging with most frequently used applications in Backend.AI.
- e.g., How many new dependencies to be introduced? Could we install squashfs-tools and fuse support in our customer sites?
- e.g., Does complex apps like code-server work with appimage? How complicated is packaging an arbitrary app using appimage?
- Define how to distribute and manage multiple app packages with different versions and variants (like CPU architectures).
- Relying on PyPI may not be feasible as the binary blobs may be quite large, easily exceeding the PyPI upload limits.
- We would need to define a minimal directory structure for indexing and storing appimage packages with some metadata to pack/unpack in air-gapped customer sites.
- We also need to design and implement some easy upgrade/population mechanisms when there is a large number of agent nodes.
- Idea: reuse the reservoir subsystem (Git LFS integration / Minio integration)?
- Make automated appimage build pipelines.
- e.g., [https://chatgpt.com/share/68d4dfb4-dca0-8000-b073-7cff9fd21dab](https://chatgpt.com/share/68d4dfb4-dca0-8000-b073-7cff9fd21dab)
- Design and implement app package injection to the containers.
- Add app-specific auto-configuration steps when starting containers.
- e.g., JupyterLab and Jupyter Notebook requires explicit kernel configuration to detect and execute Python runtimes specific to individual images. (Some images may use distro-based Python from `/usr/bin`, some use custom-built Python in `/usr/local/bin`, others use conda-based ones in `/opt/conda/bin`, etc. Often those image-specific Python runtimes have dedicated custom packages crucial for operation, such as optimized DL framework builds, so we need to connect with them instead of shipping our own standalone build.)

JIRA Issue: BA-2515