- Due to https://github.com/exAspArk/batch-loader/pull/32,
we  changed BatchLoader.for into BatchLoader::GraphQL.for
- since our results are wrapped in a BatchLoader::GraphQL,
calling `sync` during authorization is required to get real object
- `graphql` now has it's own authorization system.  Our
`authorized?` method conflicted and required renaming

The `GraphQL::Function` has been deprecated in
favor of resolvers.

Since the `GraphQL::ID_TYPE` usages should represent globally unique
ids, this changes some fields for which this is not the case into
strings.

The `ID_TYPE` is a specialised, so this change should be backwards
compatible.

https://graphql-ruby.org/type_definitions/scalars.html

We can query namespaces, and nested projects.

Projects now exposes statistics

and allow passing of child_complexity to the
'resolver_complexity' metho

Added repository files to GraphQL API

See merge request gitlab-org/gitlab-ce!28325

If a field is a resolver, its complexity is automatically
increased. By default we add extra points for sort and search
arguments (which will be common for various resolvers).

For specific resolvers we add field-specific complexity, e.g.
for Issues complexity is increased if we filter issues by `labelName`
(because then SQL query is more complex). We may want to tune these
values in future depending on real-life results.

Complexity is also dependent on the number of loaded nodes, but only
if we don't search by specific ID(s). Also added complexity is limited
(by default only twice more than child complexity) - the reason is
that although it's more complex to process more items, the complexity
increase is not linear (there is not so much difference between loading
10, 20 or 100 records from DB).

Add basic GraphQL for a Group

Closes #60786

See merge request gitlab-org/gitlab-ce!27492