Use operator-rs `build_rbac_resources` instead of own implementation

Issue checklist

PR https://github.com/stackabletech/issues/issues/675 fixed a bug in operator-rs build_rbac_resources to improve ServiceAccount / RoleBinding deployment.

The spark-k8s operator uses its own method build_history_role_serviceaccount (only required for the history server). Although that method does not introduce the bug fixed in https://github.com/stackabletech/issues/issues/675, it differs in terms of naming the ServiceAccount and RoleBinding (missing suffixes -serviceaccount and -rolebinding respectivly).

This should be consolidated.

A quick test lead to label differences of the ServiceAccount / RoleBinding. This needs investigation.

Generated labels using the spark-k8s-ops build_history_role_serviceaccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: node
    app.kubernetes.io/instance: spark-history
    app.kubernetes.io/managed-by: spark.stackable.tech_history
    app.kubernetes.io/name: spark-k8s
    app.kubernetes.io/role-group: history
    app.kubernetes.io/version: 3.5.2-stackable0.0.0-dev
    stackable.tech/vendor: Stackable
  name: spark-history
  ...

vs generated via operator-rs build_rbac_resources (only using cluster resources get_required_labels method):

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/instance: spark-history
    app.kubernetes.io/managed-by: spark.stackable.tech_history
    app.kubernetes.io/name: spark-k8s
  name: spark-history-serviceaccount
  ...

Start by locating the spark-k8s operator's build_history_role_serviceaccount method and the operator-rs build_rbac_resources entry point. Compare their ServiceAccount and RoleBinding names and generated labels, including the -serviceaccount and -rolebinding suffixes. Done means the history server uses the shared implementation and the label differences are understood and addressed.