Reconsider CR abstraction granularity

Feature Request

Is your feature request related to a problem? Please describe:

As the version number goes up, TiDB Operator is exposing more and more Kubernetes native abstraction details (like verbatim fields in StatefulSet) in the CRs (e.g. TidbCluster). This trend of making CRs more like Kubernetes native objects in field level is a sign of bad design. On the one side, the Kubernetes api objects are well defined and could give users more control of the behavior of TiDB Operator. On the other side, this results in a lot of work for users to understand before they could use TiDB Operator to do their job.

Describe the feature you'd like:

We should come up with a more robust and user friendly abstraction for CRs, which must make both basic level and advanced users happy.
One possible way of achieving this goal is to make separated levels of abstractions: we could expose simple APIs through CRs, and also allow the user to touch the underlying Kubernetes native objects for advanced usages.

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

Start by reviewing the TidbCluster CR fields that expose StatefulSet details and the Kubernetes native objects they represent. Identify which controls are needed by basic versus advanced users, then investigate how separate simple APIs and access to underlying objects could be designed and migrated without breaking existing CRs.