Protected finding data

[NDStrahilevitz]

1. Explain what the PR does

f72fd50 fix(finding): use thread safe finding data access
ff65fc6 chore(all): change all detect.Finding to pointers
156569e chore(go.mod): bump types

Fix #3748

2. Explain how to test it

Make sure no regression happens, this change should not fundamentally change current behavior, but rather allow correct signature authoring.

3. Design choice

I initially wanted to break the Finding struct by adding the following struct:

type FindingData struct {
     data map[string]any
      l *sync.RWMutex
}

And add the thread-safe methods to that struct. This worked perfectly fine, with the api break being functionally not hard to fix with search and replaces. Only one problem happened, the output templates in tracee-rules were broken. I've made multiple attempts at fixing it, including adding custom json marshalling, but nothing worked. The only thing which worked with no breaking was keeping the existing Data field in place and untouched.

This introduced the problem of adding the mutex into the existing struct: if we add the mutex as a pointer then using the thread-safe methods as is would cause a nil pointer reference panic. This means that either all users now need to initialize the mutex themselves, or use a constructor which is not enforced for use (except for the otherwise occuring crash). That meant that the mutex must be a non pointer value.
That lead to the problem of mutex copying. mutex copying is an issue, since the locks are now unshared, which would mean that our problem is left unresolved. the way to use non pointer mutexes is if the object itself (the finding) is always passed around as a reference. Which meant changing the whole codebase to do just that.

Why was I still ok with choosing this solution?

1. Because as explained, I couldn't find any other viable one which didn't break templates
2. Because templates and tracee-rules and all that fun stuff will likely be removed once we finish the "everything-is-an-event" project. Alongside that, the finding struct can also be removed, thereby removing this sad design choice.

[NDStrahilevitz]

TODO: types PR and bump

[AlonZivony]

LGTM