Support renaming one schema field into multiple new schema fields

[obi1kenobi]

The current code assumes that we always want to perform a 1-1 renaming of schema fields: rename a given existing field into a new field. However, this presents a catch-22 migration problem. Imagine you have a query that uses the field being renamed — you can't rename the field without breaking the query, and you can't modify the query to use the new name because the new name isn't present in the schema yet.

One way to avoid this issue is to change the type signature of the renamings argument, making it Dict[str, List[str]] mapping existing schema field names into a list of renamed field names, each of which represents the same underlying schema field. It also presents a unique opportunity to streamline our interfaces: mapping a field to the empty list can represent suppressing the field entirely. Field names X that exist in the schema but are not in the renamings mapping are defined to be equivalent to being mapped to [X], the identity mapping.

This approach resolves the catch-22 migration problem: we are able to update the schema to contain both the original and the desired new field name, then update the query to use the new name, then update the schema again to remove the original field name, completing the migration.

[LWprogramming]

List of the remaining tasks, for reference:

• Error checking improvements (various: e.g. every renaming in renamings must be used, error on 1:1 renaming something to itself, raise all errors at once instead of one per invalid GraphQL name, etc)

• Suppress fields

• Suppress enums & interfaces (edge case with suppressing implementation but not the original interface)

• Code cleanup (i.e. if we can get away with not storing O(schema size) data in reverse_name_map and not needing query_type as a parameter anymore)

• 1-1 and 1-many renaming for enum values as well as fields (whether belonging to object or interface). Requires modifying rename_query as well