[FEATURE] Introduce the general client conf for mr/spark

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

### Search before asking

- [X] I have searched in the [issues](https://github.com/apache/incubator-uniffle/issues?q=is%3Aissue) and found no similar issues.

### Describe the feature

Introduce the general client conf for mr/spark
1. Introduce the class of `RssClientConf` to set the general configOptions for mr/spark
2. Introduce the class of `RssSparkClientConf` to set the spark exclusive `configOptions` and to construct the RssConf from the `SparkConf`
3. Introduce the class of `RssMRClientConf`

I proposed a PR #200 before, but it looks this part needs to do much changes.

### Motivation

Now in mr/spark client conf, we don't obey the rule of uniffle `configOptions`. It causes the some problems as follows

1. When introducing the client general conf, we have to write three times in `RssSparkConfig`/ `RssClientConfig` / `RssMRConfig`. Actually there is no need to leave dirty works for developers.
2. If when introducing a general method for MR/Spark and need to some configs from Rss client conf. In current implementation, we have to introduce extra class for method's params. If we having the general RssClientConf, it will benifit more.

### Describe the solution

_No response_

### Additional context

_No response_

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

Start by comparing the existing RssSparkConfig, RssClientConfig, and RssMRConfig classes and how SparkConf is converted into RssConf. Review the earlier PR #200 and the current configuration options before deciding how RssClientConf, RssSparkClientConf, and RssMRClientConf should divide responsibilities. Done means general options are defined once and Spark- or MR-specific options remain isolated without duplicated configuration work.

Written by the indexing model from the issue text.