Improve Python SDK dependency management strategy

[Peilun-Li]

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

As discussed in WG meeting (notes), it'd be better if we could improve our kserve python SDK dependency management strategy for easier customer adoption. Specifically, the current pain points are:

1. strict equal (==, boto3) and tilde equal (~=, numpy) do not perform well in terms of backward & forward compatibility, and introduce unnecessary restrictions as a "middle-layer" SDK (downstream customer may have specific reasons to use other versions of boto3/numpy, thus making KServe SDK hard to adopt)
2. Similarly, dependency requirements (even under the >= cases) should ideally be as relaxed as possible, so that customers using some old version of dependencies can still enjoy later version of KServe SDK.
3. Not all dependencies declared as a requirement are actually used by customers, e.g., some customers may not need boto3/azure/google libraries depending on their cloud provider choice; some customers may not need ray[serve] if they are not using parallel inference feature. Such too broad hard dependency pattern can introduce additional risk on adoption, e.g., if one unnecessary dependency can't be installed (example)or introduces conflict in customer env.

Suggestions for dependency management:

1. Use >= instead of ~=/== if possible
2. The dependency version requirement should be as relaxed as possible (e.g. the lower the version number the better) so the python sdk could be more adoptable (give the freedom to pick dependency versions to downstream packages)
3. Introduce optional dependencies (example) to separate out core functionalities from optional functionalities. Some candidates for optional dependency can be ray and cloud provide specific packages.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

[alembiewski]

Thank you for this proposal. I think it definitely makes sense, especially to ensure better compatibility with other libraries.
Numpy version cap is what we discovered recently and it prevents us from using some of the libraries that require a more recent numpy package version, raised a PR