…180016)

## Summary

This pr makes use of a new prop (and some generic memoization fixes) in
2 eui prs merged recently (elastic/eui#7556 and
elastic/eui#7374) to improve the performance of
the alerts table. Mainly, the cellContext prop is now available to
consumers of the triggersActionsUi alerts table to pass in custom props
in a way that allows the renderCellValue/rowCellRender functions of the
various EuiDataGrid prop apis to remain referentially stable across
re-renders. There are also some various changes to various hooks and
props found throughout plugins that use the table to improve
performance. There should be no change in functionality, just a moderate
to substantial reduction in time the app spends rendering the alerts
table in various scenarios. Below will be some react dev tools
performance profiles, main compared to this branch, with the exact same
set of generated data.

Main, switching from 10-100 rows:

![main_alerts_table](https://github.com/elastic/kibana/assets/56408403/6b87093f-5b1b-4d22-8e23-ccc3406317f4)

This branch 10-100 rows:

![context_alerts_table](https://github.com/elastic/kibana/assets/56408403/75bf5d53-045d-42ae-979a-e52d6c0f8020)

Pretty modest gain here, 1 render is slower than any others on main, but
overall less time spent rendering by about a second.

Main, opening the cell popover on 2 cells

![main_open_cell_popover](https://github.com/elastic/kibana/assets/56408403/60c5d132-b526-4859-a29c-5d3157142d50)

This branch, opening cellpopover

![context_open_cell_popover](https://github.com/elastic/kibana/assets/56408403/2c60b250-6a9f-44b4-aec8-f9dcb8c87531)

Again nothing crazy here, modest improvement.

Main opening timeline and hitting refresh


![main_open_timeline](https://github.com/elastic/kibana/assets/56408403/7525200d-cf9b-4f43-9f24-43f314740db1)

This branch, opening timeline and hitting refresh


![context_open_timeline](https://github.com/elastic/kibana/assets/56408403/efd3cf95-a81a-4933-b310-fa61de24258f)

This is the case that brought this about in the first place, as security
solution shares a lot of code between tables, the alerts table
recreating all cells on every render was destroying performance of the
timeline rendering in a flyout/modal while users were on alerts page or
the rule detail page, which is probably the most common use case. 93ms
in this branch vs 2500+ ms in main. This type of performance hit happens
when almost any action is taken in timeline.

Main, selecting 3 alerts 1 at a time

![main_actions](https://github.com/elastic/kibana/assets/56408403/87487149-cf6d-4bcc-9192-b64411abe321)

This branch selecting 3 alerts 1 at a time


![context_actions](https://github.com/elastic/kibana/assets/56408403/8407953a-5af0-4cfd-9f2c-08c710c81fb3)

Pretty substantial improvement here as well, ~2000ms vs 67ms.

Apologies if some of the gifs are cut off, please try the branch vs main
on your own! This was done on a local kibana in dev mode, so things like
emotion are eating up more cpu than they would for a user, but there
still should be improvement, and I can't think of any circumstance where
things will be worse. Also this branch was a little longer lived than I
would have liked, so if you are reviewing and changed something around
these files recently please double check I didn't miss anything.



### Checklist

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios