[Security Solution][Detections] Address cyclomatic complexity issue in RulesTables component

[banderror]

RulesTables component kept slowly growing in terms of LOC and needed refactoring.

This PR #91925 has added a few changes so that the cyclomatic complexity limit has been exceed, and I had to temporarily disable the corresponding ESLint rule for the whole file.

While I'm feeling like the whole rules management table and its parent page component need to be fully refactored, this ticket aims to address this specific issue. Maybe there is an easier way to do just that without starting a full-blown refactoring (#92169).

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[xcrzx]

It is not related to the component's complexity, but In regards to the slow table rendering performance, we could implement these improvements:

• Introduce virtualization to render only rows that are currently visible to a user. This could cut up to 80% of rendering time for large tables (100+ rows). However, it might not be that easy and require migration from EuiTable to another component.
• Reduce the overall amount of the table's nested DOM elements wherever possible. For example, hide elements for mobile view with js instead of CSS.
• Optimize the table's state so that it doesn't trigger re-rendering of the entire tree on every change.

[xcrzx]

We also need to refactor the rule table’s state to avoid hacks like useValueChanged altogether. See related discussion: #100554 (comment)

Current problem:

1. EuiBasicTable uses an array of table items (in our case, Rule[]) to keep track of currently selected rows.
2. But our RulesTables uses an array of rule IDs to do the same.
3. We synchronize the two states manually. If we receive a selection change event from EuiBasicTable, we map rules to their ids (Rule[] => string[]). And vice versa, if we change the selection state in RulesTable, we map IDs to rules. (string[] => Rule[]).
4. That makes usage of plain useEffect impossible because the above transformations create a new array every time, which will lead to an infinite loop of re-renders.

We could solve the problem by refactoring the RulesTable state to store selected rule objects instead of just rule IDs and by dropping Rule[] => string[] maps. And by doing that, we could switch from useValueChanged to useEffect.

[xcrzx]

Another thing that we could refactor is getBatchItems(). It's a method that makes a bunch of API calls, but it is not a React component or hook. It doesn't allow to pass down an abort signal, as it wouldn't make sense because there is no lifecycle method to call abort().

We need to refactor getBatchItems() to a hook, like useBatchItems(), and implement proper request cancellation logic.

Original discussion: #100554 (comment)