Diff returns all nested changes for additions

[jdolle]

Description

This adds fields that are necessary for recreating the patched schema using the input schema and changes array.
This PR modifies the TypeAdded change type to add a Kind, and modifies the onAdded handlers to also execute equivalent logic to onMutual.

This has a few down sides and an important up side.

Cons

1. Increased noise when listing changes
2. Increased complexity because it blurs the line between changes and additions. Although arguably some of the changes did this already.
3. It requires adjusting some of the criticality of these changes when they are created from within the onAdded call. Because e.g. adding an interface to newly create object is completely safe, but adding an interface to an existing object is considered dangerous.

Pro

1. Does not require parsing additional change events or nested metadata within addition events.

The best alternative approach I could come up with is to add metadata to the "added" change events. This is doable, but requires essentially recreating all the parsing that is already done in onMutual, and then requires any logic using these events to also recreate logic for adding things to the schema, because for example a field could be added to a type via a FieldAdded change OR within a TypeAdded change. And the structures would not match.
This approach would make the meta data very large also, because it would have to capture interfaces, directives, fields, etc..
However, it would prevent us from polluting the existing change set with more noise.

One final idea I had is to add a configuration option to only call the onMutual logic if a boolean "captureAllChangesOnAdd" is set to true.

---

An additional change is that multiple changes are no longer returned for the same "node". e.g. When adding a deprecated directive with a reason, the reason field is on the added change, and a "deprecatedReasonAdded" change is no longer emitted.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

See unit tests.

Checklist:

• I have followed the
  CONTRIBUTING doc and the
  style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[jdolle]

In these cases, the type is being used to extract the name only. It doesn't matter if we pass the new or old directive, since the name is the same. However, since calling these functions onAdd -- the old type can be null, which is why this was changed to pass the new type (newDirective)

[jdolle]

This test shows that enum additions also contain all nested changes within that enum, and that those changes are flagged as non-breaking.

[jdolle]

^ very curious why... It doesn't change behavior/how clients interact. "Dangerous" seems extreme.

[jdolle]

Should this filter out the deprecated directive since that's captured by another change?

[jdolle]

I could be convinced that this is a minor patch because the changes to the output's format doesnt break anything. But the actual content of the changes has changed drastically which is why I thought we should be safe and declare a major change.

[jdolle]

This allows us to reduce noise when running the diff. If the parent was added during this change set, then the change will be excluded from the list.
See tests for what this looks like in practice.