Refactor Global Search initial view components

What does this MR do and why?

This refactors the architecture of how the global search initial view.

This will make it much easier to add the frequently visited projects/groups in a future MR, as part of #409522 (closed).

See commit messages for more detail.

Commits

Add new default places component

This is the first commit of a refacting of how the global search modal's initial view is implemented.

This component is extracted from the global_search_default_items.vue component, and represents the "Places" group of items shown in the global search modal's initial view.

The idea is to extract each group displayed in the initial view to its own component. Each component will:

• be responsible for getting its own data,
• render a GlDisclosureDropdownGroup as its root vnode,
• transparently pass all attrs to it (e.g., bordered),
• not render anything if they have no data,
• emit a nothing-to-render event if they have nothing to render.

A later commit will explain the rationale for these details.

Part of #409522 (closed).

Add new default issuables component

This is the second commit of a refacting of how the global search modal's initial view is implemented.

This component is extracted from the global_search_default_items.vue component, and represents the context-dependent group of links to issues and merge requests shown in the global search modal's initial view.

Part of #409522 (closed).

Refactor default items component

This rewrites the global_search_default_items.vue component to consume the components created in the previous two commits.

As stated in an earlier commit, each of the sub-components will:

• be responsible for getting its own data,
• render a GlDisclosureDropdownGroup as its root vnode,
• transparently pass all attrs to it (e.g., bordered),
• not render anything if it has no data,
• emit a nothing-to-render event if it has nothing to render.

Before this, the global_search_default_items.vue had several responsilibities:

• fetching data for each group, from different sources (provide/inject, Vuex store, and soon to be localStorage (see below)),
• rendering each group, including their headings and items,
• deciding when a group should and should not render,
• handling border/spacing between rendered groups.

One of the goals of #409522 (closed) is to add frequently visited projects and groups to the global search modal's initial view. As that data is stored in localStorage, that would mean added even more data-fetching logic to this already unwieldy component.

This new architecture simplifies global_search_default_items.vue. Its responsibilities are now:

• Attempt to render its sub-components.
• Stop rendering a component when it emits a nothing-to-render event.
• Handle border/spacing between the components which have rendered.

The complexity of data fetching, knowing when and how to render is encapsulated by each sub-component.

Part of #409522 (closed).

Screenshots or screen recordings

There should be no visual change introduced by this MR. But, here is how it should look anyway:

State	Screenshot
Logged in, no context
Logged out, no context
Logged in, group context
Logged out, group context
Logged in, project context
Logged out, project context
Logged in, project context, issues disabled
Logged out, project context, issues disabled

How to set up and validate locally

Logged out state

1. echo "Feature.enable(:super_sidebar_logged_out)" | rails c
2. Visit a publicly visible page, like a public project, group or /explore. (The root path / redirects to the login page, so isn't useful.)
3. Open the search modal by pressing /, or clicking the search icon in the sidebar.

Logged in state

1. Visit any page.
2. Open the search modal by pressing /, or clicking the search icon in the sidebar.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.