[feat]: [CDS-73030]: Support for text based branch filtration

[adivishy1]

Have added code for supporting text based branch filtration for the following git providers:

1. Bitbucket cloud
2. Bitbucket server
3. Azure
4. Gitlab

Note: Github does not provide support for text based search.
Have tested out string based search all the above providers. For the other drivers that implement the GitService interface, have called the listBranches method which means that its not filtering based on any branch being passed.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[tphoney]

i have a few questions.
what do you expect the search term to look like ? do we need to encode that search term differently for each scm provider ?
why dont you just use the url operation that is part of the listBranches ?
why is it named v2 , this has no meaning

[adivishy1]

1. what do you expect the search term to look like ? : it can be anything that user types, say if we have branches such as test, main, main-patch, main-patch1, main-patch-12 cds-12312, etc, and the user wants only branches where "main-patch" in present, then in such case the user can pass search term as "main-patch" or "patch" or "main-" the the git providers that support such functionality
2. do we need to encode that search term differently for each scm provider ? yes, each of them take the filter params in a different query param name, eg azure takes it as "filterContains=" ,bitbucket saas takes it as "q=name~" etc,
3. why dont you just use the url operation that is part of the listBranches?: there are cases where the url changes slightly, like in the case of azure, in existing impl of ListBranches, there is a query param includeMyBranches=true but we cannot have includeMyBranches and "filterContains=" together in the same url, hence new listBranchesV2 with new query params in the url
4. why is it named v2 , this has no meaning: Purely for backward compatibility purpose, for implementing this functionality, we would need a new param, searchTerm to the existing listBranches method, if we directly add it as new param, that would break the previous usages of the go-scm lib, hence listBranchesV2 and once everyone are on board with the ListBranchesV2, then gradually we can deprecate the listBranches method