fix(git): fix repo scan result caching

[vvagaytsev]

What this PR does / why we need it:

This PR fixes cache key construction in GitRepoHandler that accounts for different includes/excludes and filter functions for the same path.

Originally, the caching was implemented in #5710. This PR makes sure that 2 filter-objects are considered tom have the equal cache keys if the difference is only in the order of the augmentedExcludes and augmentedIncludes arrays, ad there is no difference between the sets of values of both arrays.

Which issue(s) this PR fixes:

A follow-up PR for #5526 and #5710

Special notes for your reviewer:

The changes made #5710 make the caching in GitRepoHandler.scanRoot(...) unnecessary. That caching logic will be removed in a separate PR. The caching in GitRepoHandler.scanRoot(...) might still make sense. It caches the results for the whole path, without taking include/exclude filters into account.

[stefreak]

Nice, looks good to me and this is a good fix

I have one minor comment about the function signature of getHashedFilterParams; I want to make sure that we are not hiding details that are important later to understand implications of making changes to the code

[stefreak]

Because it's such an unusual thing to do, and it has some implications (e.g. captured variables will not affect the hash key) I think it's better to not hide the fact that we are converting the function to a string, by changing the signature of the function, something like the following:

export function getHashedFilterParams({
  filterFnSource,
  augmentedIncludes,
  augmentedExcludes,
}: {
  filterFnSource: string | undefined
  augmentedIncludes: string[]
  augmentedExcludes: string[]
}) {

[stefreak]

Let's merge this anyway, the nit can also be addressed later.