add sklearnserver rock

[ca-scribner]

adds a rock for the kserve v0.11 sklearnserver based on this dockerfile and the existing Paddle and pmmlserver rocks

This PR refactors a little compared to the previous rocks like pmmlserver. The main goals were:

• improve readability (the pmmlserver uses a lot of magic but doesn't explain why/how it works - I've tried to add comments here)
• make the image API interchangable with upstream as much as possible (no need for pythonpath or calling python3)

Specifically for the pythonpath, the pmmlserver rock needs to add /pmmlserver:/kserve to its service PYTHONPATH because poetry by default installs a root project as editable, which means the code is not stored in dist-packages like the other installed packages. So when we copy our installed python packages from build env to the final rock in pmmlserver, we omit the pmmlserver and kserve packages (and then we "fix" that by copying the code separately, and adding the new code dirs to PYTHONPATH.

I'm worried this PYTHONPATH workaround might have unintended consequences, so instead in this rock I install kserve and sklearnserver packages as local dependencies of a dummy poetry project rather than as root projects. This tricks poetry into installing them normally (not editable), which means they are put in dist-packages like everything else.

Testing instructions

cd sklearnserver
rockcraft pack
sudo skopeo --insecure-policy copy oci-archive:sklearnserver_0.11.0_amd64.rock docker-daemon:charmedkubeflow/sklearnserver:0.11.0
docker run charmedkubeflow/sklearnserver:0.11.0

The rock should launch, but then fail with:

2024-02-15T20:42:59.351Z [sklearnserver] main.py: error: the following arguments are required: --model_dir

[ca-scribner]

PR is missing the tox.ini/tests folder. will add these next before merging this. But the rock itself works afaict in local testing

[ca-scribner]

PR is now ready for review, with proper tests. Any CI failures now are not intentional

[DnPlas]

After a sync with @ca-scribner, we have agreed that the pattern that this rockcraft project follows must be documented in a CONTRIBUTING.md file so it is more clear how to deal with these kind of rocks, as some workarounds were put in place to make things work similarly to the Dockerfile it is based on.
I'll do another pass once we have documented everything that's needed (separate PR).

[DnPlas]

Thanks @ca-scribner. The contributing guide in #27 makes all the workarounds in this rock easier to understand, and after our discussion yesterday, I think we can carry on with this approach for similar kserve server rocks.