[Discussion] Modularize distrobox

As discussed in #511 , the best way to make integrating other runtimes easier and better is to "modularize" distrobox. This would involve pulling out common code into functions and making the scripts that are actually called by users only focused on parsing the CLI.

@89luca89 started working on this in #430 but this branch has gone stale and lost many improvements that have been put onto main. I tried a simple rebase and a simple merge and neither was easy. I think the best solution is to re-branch off main and re-do this modularization.

My goal of using the apptainer/singularity runtime informs the proposed design. From #430 , it looks like the actual unique commands are `create`, `enter`, `list`, and `rm`. (I am adding `list` and `rm` since I know that the apptainer/singularity interface will need a different implementation than the docker/podman).

## Design Structure
```
- distrobox : entrypoint command
- lib/
- deduce_manager : deduce what container manager (and what group) to use from env variables and/or autodetect
-
- docker/
- create
- enter
- rm
- list
```
with this setup, then `distrobox` can have the function definition doing a specific task change depending on the container manger.
```
. "$(dirname "${0}")"/../lib/"${deduced_container_manager_group}"/
```
could define the necessary function to run that would be given the arguments deduced by the CLI or, perhaps even easier, the file at `$PREFIX/lib//` is a POSIX script itself.

Currently, since podman has the same CLI as docker, they would both belong to the same "group". Grouping managers into similar (or even identical) CLIs allows us to save on code duplication. Similarly apptainer and singularity would share a group.

Each container manager group would be required to perform the `create`, `enter`, `rm`, and `list` tasks. Other tasks that require `docker inspect` (like automatic removal of the container's home directory) would not be implemented for other container groups, but this structure allows for more "fundamental" tasks to be defined in order to unify the CLI across different managers.

---

@89luca89 I plan to start work on this and I am hoping for your feedback. I think this could supersede #430 but also I plan to copy over the work you did with starting to write tests and updating the install script to handle the `lib` directory install as well. Moreover, I'm curious about the other PRs currently open - should any of them be merged _before_ these developments? (i.e. to try to avoid the stale-ness that happened last time).

此 issue 描述了對 distrobox 腳本進行模組化。首先檢查主要的 entrypoint script 以及儲存庫中現有的程式碼結構。找出可以移至 lib/ 目錄的通用函式，並了解目前如何處理容器管理器（docker/podman、apptainer/singularity）。目標是建立一種設計，將各管理器專用的 create、enter、rm 和 list 實作分離。檢視已過時的 PR #430，以了解先前的工作與測試。

由索引模型根據 Issue 內容生成。