chore: Drop dependency on fork of go customruleset fixtures

What does this MR do?

Now that the upstream MR has merged, we should rely on the original instead of fork

See !171 (merged) that introduced this dependency and background on why.

Because the upstream fix was to not deduplicate the two rules and to just give them slightly different identifiers we essentially have a duplicate rule here. This isn't ideal from a ruleset perspective but it works here in successfully demonstrating rule synthesis so I think it's okay for now. Especially given my main goal was to not have reliances on personal forks when possible

Does this MR meet the acceptance criteria?

• Changelog entry added
• Tests added for this feature/bug
• Conforms to the code review guidelines
• Conforms to the Go guidelines
• Security reports checked/validated by reviewer