[Saved Queries] Improve saved query management followups

[davismcphee]

Followup to #170599.

There are a few outstanding concerns around the changes made in #170599 that we should figure out how to address. Some are technical changes/cleanups, and some are UX concerns which will require design input to improve.

UX changes

• The "1 selected" text displayed when a query is selected in the list is confusing since it might imply that multiple queries could be selected, when 0 or 1 are the only valid values. This display helps users understand that there's still a query selected when they change pages or searches, but we should consider how to make it clearer.
  
• Currently we pull the active/selected query to the top of the first page of the saved query list to make it clear to users which query is currently selected when opening the list. This improves visibility of the selected query, but results in the first page including an extra query compared to other pages when there's a selected query, and causes the query to appear twice in the list since it will also appear on the page where it would regularly be shown. This should be addressed along with the "1 selected" text to ensure it's clear to users which query is selected when they open the list, but not require moving the selected query to the top or having it appear on multiple pages.
  
• The saved query "Name" input is disabled for query updates even though the update endpoint supports it. This appears to be an intentional UX decision, but it's worth reconsidering if this is necessary or not.
  

Technical changes

• In order to make the query search functionality work, we have to prepare the provided search term before passing it to the KQL query. Part of this includes stripping non-alphanumeric characters from the search term. This works for most cases, but some punctuation is actually retained by ES when generating terms from the title text (e.g. ' in what's), so we should refine the regex used to retain characters we know can be included in the generated terms.
• Switch from KQL to DSL for query searching. Currently the saved objects client only supports simple query string syntax or KQL for searching, which limits our ability to perform the required case-insensitive wildcard query we'd need to replicate the previous filtering mechanism (case-insensitive exact match of any part of the title).
• Consider removing the deprecated saved_query/_all endpoint. We deprecated the endpoint in the original PR and updated it to limit the number of queries it returns due to performance concerns, but we should consider what it would take to drop the endpoint entirely in a backward compatible way.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[ghudgins]

@davismcphee / @ninoslavmiskovic can this become a sessions task or close?

[ninoslavmiskovic]

@ghudgins Saved ES|QL views, starred queries, and other related assets will be handled as part of the Discover Sessions work. The current saved queries are not the primary focus at this stage, though we can consider cleanup efforts later. We’ve intentionally excluded saved queries from the initial discussion to maintain clarity and focus.