Convert <ViewInstance> to use data from GraphQL query

I think it may be worth keeping that one alive, since it's just a longstanding dream to have an inventory view that's a collapsible tree of instances, holdings and items. But I don't know of any funding in the pipeline to make it happen.

Thanks, @Mike Taylor. Same with UIIN-183?

This is ancient and has long lost all relevance. I am closing it as WONTFIX.

Quick recap. We have a graphql branch of ui-inventory that uses the GraphQL response to populate a somewhat richer <MultiColumnList> that includes the linked instanceType field. And we are able to see in the browser's Network tab that when we view an instance, we're successfully retrieving a rich structure consisting of an instance, its holdings, and their items.

That being so, we know we can progress this work when we need to. See the closing comment on https://folio-org.atlassian.net/browse/UIIN-180#icft=UIIN-180 for some thoughts on how best to do this – in short, by simply ripping out the existing stripes-connect client code from <ViewInstance> and its sub-components, and replacing it with a single big query in ViewInstance whose result (or part of it) is passed into each sub-components.

Our present judgement is that the most urgent part of the GraphQL work is now auto-generation of GraphQL schemas and resolvers (https://folio-org.atlassian.net/browse/MODGQL-20#icft=MODGQL-20), so we are deferring client-side work until that's been done.

I am therefore blocking the present issue on https://folio-org.atlassian.net/browse/MODGQL-20#icft=MODGQL-20: it's not logically blocked by it, in the sense that both issues could proceed in parallel; but it's logistically blocked because we've decided to do the two tasks in that order.

I'm also assigning to @Niels Erik Nielsen, since we agreed on today's call that he, with his intimate knowledge of the Inventory app, is better placed to make the transplant, and will recognise if something goes wrong. He'll pick it up when it's unblocked.

As noted in https://github.com/folio-org/ui-inventory/commit/bc75e2af252b9e680b72b70c84c67c5cf257afb6 ...

We presently have an only slightly richer record from GraphQL than from stripes-connect, which includes the following fields not included in the stripes-connect records:

• instanceFormat

• instanceType

• edition

• instanceFormatId

• __typename

Of these, __typename seems to be a GraphQL-internal field, always with the value Instance, so it's not much use to us. I don't know what instance-formats are – that needs domain knowledge that I lack. edition might be of interest, but resource-type suffices to make the point that we're getting enhanced data, so I have enhanced the {[graphql}} branch of ui-inventory to display a Type column as well as Title, Contributors and Publisher.

(There is a problem, though: because GraphQL is only being used to assemble a rich record, and the actual querying is still left to CQL, we're limited in our sorting options to what the CQL provides. In the case of resource-types, that is the ID of the type rather than its name. As a result, clicking on the "Type" column heading does sort by type, but it's only by happy accident that right now the three types that exist in our system happen to have IDs that sort in the same order as their names. In other words, sorting by resource-type seems to work, but it's an illusion.)