This implements the same thing we implemented for [issues](
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40669
) and [merge requests](
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42560
) now for Epics. This required a slightly different approach as the
`EpicsFinder` was not suitable for this purpose. At present it only
supports searching within a single group. And extending it to support
wider use cases would likely lead to performance issues as there is no
equivalent group permissions cache like `project_authorizations` table
to efficiently determine which groups a user can view epics in.

The simpler thing to do here was to just manually check the permissions
for each returned epic. This leaves a very edge case scenarion in which
a user was previously able to see an epic and looked at that epic in
their last 100 viewed epics and then performs a search and now only sees
4 suggestions (instead of the expected 5). This in theory, if the epic
was renamed and the new name contained something important the user
shouldn't see, could lead to the leak of an existence of that name in
the search results. Considering this edge case is so unlikely it seems
safe to not worry too much about it.