Remove optimized_issuable_label_filter flag

What does this MR do and why?

Removes the optimized_issuable_label_filter feature flag and refactors the label filter into its own class.

This is similar to what we did with Issuables::AuthorFilter and Issuables::AssigneeFilter. This is done so that the IssuableFinder can be split into more files and logic won't be split between IssuableFinder and IssuableFinder::Params. This makes it easier to add the OR filters. OR filters are already added for author and assignee but I did not do it here for labels. I'll do that separately.

Related to #333965 (closed)

Minor query change for negated label filters

Because of the refactor, I also updated the negated labels filter to use the same optimization done in OptimizedIssuableLabelFilter where we find the label IDs first if possible, then filter using the IDs. The query is already very similar the only difference is the use of IDs instead of label names.

Before:

SELECT "issues".*
FROM "issues"
WHERE "issues"."project_id" = 278964 AND 
  ("issues"."state_id" IN (1)) AND
  NOT (EXISTS (
    SELECT true
    FROM "label_links"
    INNER JOIN "labels" ON "labels"."id" = "label_links"."label_id"
    WHERE "label_links"."target_type" = 'Issue' AND
      "label_links"."target_id" = "issues"."id" AND
      "labels"."title" IN ('devops::plan')
  )) AND
  "issues"."issue_type" IN (0, 1)
ORDER BY "issues"."created_at" DESC, "issues"."id" DESC
LIMIT 20 OFFSET 0

https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/6542/commands/22665

After:

SELECT "issues".*
FROM "issues"
WHERE "issues"."project_id" = 278964 AND
  ("issues"."state_id" IN (1)) AND
  NOT (EXISTS (
    SELECT "label_links".*
    FROM "label_links"
    WHERE "label_links"."target_type" = 'Issue' AND
      "label_links"."target_id" = "issues"."id" AND
      "label_links"."label_id" = 3103451 LIMIT 1
  )) AND
  "issues"."issue_type" IN (0, 1)
ORDER BY "issues"."created_at" DESC, "issues"."id" DESC
LIMIT 20 OFFSET 0

https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/6542/commands/22667

Note: Using IDs isn't always faster because there's the extra overhead of finding the IDs from the label names but I think they are faster most of the time since we kept this optimization for our AND filters.