Prepending CC with ccache confuses some build systems

I recently created a recipe to build python-zstandard, a Python module with a native component. I encountered an issue where the build script was attempting to run `ccache` on its own with some compiler flags, similar to #1398. This happened because:

- We have ccache installed on the host.
- In python-for-android, if `ccache` is available (and not disabled), it is prepended to `CC`: https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/archs.py#L158-L195. This results in something like `CC="ccache gcc"`.
- In python-zstandard's build system, it assumes the first item in `CC` is the _compiler_, and uses that on its own, adding a new set of parameters: https://github.com/indygreg/python-zstandard/blob/main/make_cffi.py#L31-L66. This is frustrating, [but not an uncommon assumption](https://codesearch.debian.net/search?q=compiler.compiler[0]&literal=1).

Since I have the luxury of a project that only needs to build one way, this is how I worked around it on my end:

https://github.com/endlessm/kolibri-installer-android/commit/7e4eab72da2e888d59fc058f9c36ad636a64e3b8

So, instead of patching the module or changing the environment variable, I told P4A to stop thinking about ccache, and enabled it _on the host_ by setting `PATH="/usr/lib/ccache:$PATH"`. This works because `/usr/lib/ccache` is a directory full of look-alikes for different compilers, all of which point to `ccache`. It is one of two recommended ways to use ccache: https://manpages.ubuntu.com/manpages/jammy/man1/ccache.1.html.

My suggestion here is that the current approach is problematic, and perhaps dealing with ccache on the host instead of in P4A would be a good practice to recommend in general.

pythonforandroid/archs.py の158〜195行目から始め、続いてリンクされている #1398 の議論と ccache の使用に関するガイダンスを確認します。プロジェクトが CC の処理を変更すべきか、ホスト側での ccache の設定を推奨すべきかを判断します。選択したアプローチが明確に文書化または実装され、その build への影響が検証されれば完了です。

索引モデルが issue の本文から書いたものです。