feat: allow deprecated on input fields and field arguments

[amritatwal]

Description

Allow @deprecated on input fields and field arguments.

Schema diff already modeled deprecation for output fields but input fields and field arguments did not get the same treatment. Those deprecations were easy to miss or only surfaced indirectly through directive-usage changes.

This PR adds first-class deprecation diffing for:

Input object fields — new INPUT_FIELD_DEPRECATION_* change types (added / removed / reason added, changed, removed), aligned with the existing field deprecation logic (including the default reason "No longer supported").

Field arguments — new FIELD_ARGUMENT_DEPRECATION_* change types with the same semantics.
isDeprecated now accepts GraphQLArgument so argument deprecation is detected consistently. Input field and argument directive lists are compared the same way as output fields (always compareDirectiveLists(..., || [])), avoiding gaps when lastNode.directives is missing on one side.

Supporting updates: ChangeType / Changes map, simplifyChanges, compare-changes meta keys, patch “addition” classification, and core exports.

Fixes #2199

Type of change

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

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can
reproduce. Please also list any relevant details for your test configuration

• Unit tests in packages/core/__tests__/diff/input.test.ts (deprecation added/removed, reason churn, “added with reason” / dual changes on @deprecated path)
• Unit tests in packages/core/__tests__/diff/argument.test.ts (same scenarios for field arguments)
• pnpm check (TypeScript)
• pnpm test / targeted vitest for packages/core and packages/compare-changes

Test Environment:

• OS: macOS
• @graphql-inspector/core
• NodeJS: v24.11.0

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