[8.17](backport #6192) Use xxhash instead of sha256 for hashing AST nodes

[mergify]

What does this PR do?

We currently use sha256 for hashing AST nodes when generating configuration. This is used both for checking equality between AST instances and for avoiding recomputing inputs unnecessarily. This PR changes this to xxHash, which is much faster. It also changes the interface, letting the caller supply their own hasher instance, and avoiding needing to allocate one for each Node in the tree.

Of note is that I'm using the xxhash.Digest struct as an argument instead of the generic hash.Hash64 interface from the standard library. The reason is that the former has an optimized WriteString method, which avoid needing to cast the string to a byte slice. I also don't expect to need to actually supply different hash implementations to this method.

Note also that there's already fairly exhaustive tests for this, some unexpected behaviour included.

Why is it important?

It's a pretty significant performance improvement. See the benchstat results using the benchmark from #6180:

goos: linux
goarch: amd64
pkg: github.com/elastic/elastic-agent/internal/pkg/agent/application/coordinator
cpu: 13th Gen Intel(R) Core(TM) i7-13700H
                                      │ bench_main.txt │           bench_hash.txt            │
                                      │     sec/op     │    sec/op     vs base               │
Coordinator_generateComponentModel-20     37.99m ± 24%   34.29m ± 14%  -9.73% (p=0.009 n=10)

                                      │ bench_main.txt │           bench_hash.txt            │
                                      │      B/op      │     B/op      vs base               │
Coordinator_generateComponentModel-20     34.22Mi ± 0%   31.53Mi ± 0%  -7.88% (p=0.000 n=10)

                                      │ bench_main.txt │           bench_hash.txt            │
                                      │   allocs/op    │  allocs/op   vs base                │
Coordinator_generateComponentModel-20      810.7k ± 0%   713.0k ± 0%  -12.05% (p=0.000 n=10)

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool

Related issues

• Relates Elastic agent uses too much memory per Pod in k8s #5835
• Related Memory Consumption Issue with Elastic Agent on Kubernetes with high number of resources #5991

---

This is an automatic backport of pull request #6192 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 9c13110 has failed:

On branch mergify/bp/8.17/pr-6192
Your branch is up to date with 'origin/8.17'.

You are currently cherry-picking commit 9c1311073b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   NOTICE.txt
	new file:   changelog/fragments/1733238171-use-xxhash-for-ast-hashing.yaml
	modified:   go.mod
	modified:   internal/pkg/agent/transpiler/utils.go

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   internal/pkg/agent/transpiler/ast.go

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b mergify/bp/8.17/pr-6192 upstream/mergify/bp/8.17/pr-6192
git merge upstream/8.17
git push upstream mergify/bp/8.17/pr-6192

[mergify]

This pull request has not been merged yet. Could you please review and merge it @swiatekm? 🙏

[elastic-sonarqube]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 40%)

See analysis details on SonarQube