Fetch affiliated repos from code hosts for repo selection screen.

Created by: arussellsaw

In order to support the new code host repo selection & management UI (https://github.com/sourcegraph/sourcegraph/issues/16326) we need a way to show all affiliated repos from code hosts that a user has access to.

In order to do this we'll need a new graphql endpoint to fetch the affiliated repos of a code host. logically it feels like this should live as a connection on the code host graphql object, but in terms of ease of implementation & code reuse we really want all repos returned in one list by a single query, as this allows us to drop the FilteredConnection used by the user repositories page in without any changes. Unless i can find a clean way to merge multiple connections in a graphql query or to multiplex queries in RxJS i think i'll add this as a node on the User object, fetching all repos affiliated with that user.

something like

type Query {
    ...
    affiliatedRepositories(
        user: ID!
        """
        filter to only repositories matching this query
        """
        query: String
        """
        only show repositories from this external service
        """
        codeHost: ID
        """
        which page of results to show. 
        
        note this doesn't use our normal pagination as our github client 
        doesn't paginate the same way that our postgres client does, so 
        a page number is used instead.
        """
    ): CodeHostRepositoryConnection!
}


type CodeHostRepositoryConnection {
    """
    A list of repositories affiliated with a code host.
    """
    nodes: [CodeHostRepository!]!
}

type CodeHostRepository {
    """
    The Name "owner/reponame" of the repo
    """
    name: String!
    """
    The code host the repo came from
    """
    codeHost: ExternalService
    """
    Is the repo private
    """
    private: Boolean!
}

The alternative is implementing this on the ExternalService node, but then we have the merging lists issue, one solution that @tsenart mentioned was to move each code host into their own tab, which would allow us to keep the schema a bit cleaner and still reuse the existing repo list code, but would change the designs, so i defer to @quinnkeast on that decision.

We've decided not to do any caching of the responses here, as no matter which way we spin it the user will always hit a slow load before the cache is populated, and caching would only optimise for the smaller use case of returning to this page quickly after using it, and introduce complications around staleness and invalidation.