Apply a second filter after receiving the initial repo list

Before this change, searching a repository where the prefix is similar
to the name was problematic. It sent a query having two similar
conditions which resolved to one condition. For example, searching for a
project named f/f would send a query inname:f AND inname:f. This is
problematic when listing all the related projects to the filter, which
may not correspond to the user entry. Additional examples are in [1].

Before this change, if the user entered a filter containing a special
character, the query sent to the backend was modified to correspond to
the query language. The reason behind it being that the query language
uses some special characters as operators. Therefore, the result of the
output method was inaccurate and could contain extra data that are not
needed by the user.

This change introduces a second method that compares the filter with the
output list of the fetch method. This second filter takes the original
filter and compares it with each element of the resulting array from the
fetch method. This ensures that the output received by the user matches
their entry.

With this change, users should get the same output as the old UI.

[1] https://groups.google.com/u/0/g/repo-discuss/c/pfxB4_75EL0/m/dfT-nnnMAwAJ

Feature: Issue 12970
Change-Id: I5078237a9648871eb59628d4669ffa0b5b42cc08

polygerrit-ui/app/elements/admin/gr-repo-list/gr-repo-list.js

@@ -125,7 +125,7 @@
           .then(repos => {
             // Late response.
             if (filter !== this._filter || !repos) { return; }
-            this._repos = repos;
+            this._repos = repos.filter(repo => repo.name.includes(filter));
             this._loading = false;
           });
     },

polygerrit-ui/app/elements/admin/gr-repo-list/gr-repo-list_test.html

@@ -40,6 +40,7 @@ limitations under the License.
   const repoGenerator = () => {
     return {
       id: `test${++counter}`,
+      name: `test`,
       state: 'ACTIVE',
       web_links: [
         {