Add extension point for Jenkins plugins

## Background

Jenkins has over [1800 plugins](https://plugins.jenkins.io/) from the community. This is awesome. People almost can get all that they want from those plugins. And it also makes us be impossible to support all the Jenkins plugins.

In the real world, people might want to use different plugins in their teams. So, what should they do if DevOps does not provide these plugins? What will happen if they install other plugins into [ks-jenkins](https://github.com/kubesphere/ks-jenkins)?

First, users cannot use it if one plugin provides an option. Because there's no UI support for it.

Second, the controller will overwrite the Jenkins job configuration if users maintain it from Jenkins directly.

So, there're two sides that we need to discuss. For the front-end and backend sides.

## Potential solutions

* Add [an update strategy](https://github.com/kubesphere/kubesphere/issues/3666)
* It provides the backend support

## Potential Jenkins plugins

* [pipeline-multibranch-defaults plugin](https://github.com/kubesphere/kubesphere/issues/3142)
* [git-parameter-plugin](https://github.com/jenkinsci/git-parameter-plugin)
* [active-choice-parameter](https://kubesphere.com.cn/forum/d/1301-active-choice-parameter) (in Chinese)
* [image-tag-parameter](https://kubesphere.com.cn/forum/d/2507-jenkinsfile-pipelineimage-tag-parameter) (in Chinese)
* https://github.com/kubesphere/ks-jenkins/issues/41

Start by reviewing the proposed update strategy in issue #3666 and the listed Jenkins plugin use cases. Define the front-end and backend extension points needed to support plugin options without the controller overwriting Jenkins-managed job configuration; done requires an agreed implementation scope.

Written by the indexing model from the issue text.