Remove IDs from GraphQL API

[alancleary]

By the time I'm done with #43 I will have queried every single field and subfield in our GraphQL API. What I've found while doing this is that many top-level, or "entrypoint", fields that get a single element by ID are expecting the Intermine "id" as the parameter instead of the Intermine "identifier". This is because Intermine uses the "id" as the foreign key for relationships so we need to use this internally to compute subfields. However, we want users of the GraphQL API to use the Intermine identifier when requesting specific objects because this key has meaning outside of Intermine.

The technical solution is that we need to update the Intermine data source to allow getting specific elements by their id or identifier. Then internally we can get subfields by id and externally we'll get elements by identifier. Once this is in place, I think we should completely remove the id field from all types in the GraphQL API to avoid confusing the user, i.e. identifiers will be the only externally visible IDs and ids will be an internal implementation detail.

[sammyjava]

Makes sense to me. Let me know if you'd like me to do that after you're done with #43 - (assign it to me.) FYI, some mine objects do NOT have identifiers, but that means the user doesn't get to query them, which is appropriate. (They're secondary things like expression values.)

[sammyjava]

FYI I've been doing this as I go along for quite a while. I think all top-level resolvers use identifier now. I'll fix any that don't. Of course, there are resolvers (like for Location) that must use the mine record id since they don't have permanent identifiers.

And, as you know, I'm writing internal resolvers for references and collections to use the object (like BioEntity), rather than an internal identifier (like organismTaxonId) which is only defined and used under /data-sources/, not under /resolvers/ - but that's another topic and it's in an experimental branch.