Allow epics search in specific fields with GraphQL

What does this MR do?

Related to #277065 (closed)

This MR introduces a new argument to EpicsResolver that allows us to specify the field to search in. This new argument will take a string that can be "title", "description", or a combination of both to search in either: "title,description". It is not a required argument but it will validate the presence of search is present.

This is the first usage of the :in argument in our GraphQL API so I've asked for opinions on the name in #f_graphql (internal link) where I got the following response:

Alex Kalderimis: Being consistent with the REST endpoint seems like a virtue to me. As long as the description on the argument is clear, then that seems ok to me

Currently, the REST endpoints using this param are issues and merge_requests.

Example query 1

query {
  group(fullPath: "base-group") {
    epics(search: "foo", in: "title") {
      edges {
        node {
          title
          description
        }
      }
    }
  }
}

Example response

{
  "data": {
    "group": {
      "epics": {
        "edges": [
          {
            "node": {
              "title": "Epic Foo",
              "description": ""
            }
          }
        ]
      }
    }
  }
}

Example query 2

query {
  group(fullPath: "base-group") {
    epics(search: "foo", in: "description") {
      edges {
        node {
          title
          description
        }
      }
    }
  }
}

Example response

{
  "data": {
    "group": {
      "epics": {
        "edges": [
          {
            "node": {
              "title": "Epic 2",
              "description": "Description foo"
            }
          }
        ]
      }
    }
  }
}

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.