[Error Counting] Add ID to graphql::Error

[rregitsky]

This makes two major changes to graphql::Error:

1. Adds an apollo_id UUID to errors to allow us to uniquely identify Errors. These IDs are randomly generated on construction unless one is specified by the input. Its setter is private so that Error construction is forced through new() where we randomly generate the ID. The getter is public through apollo_id(). This value is not serialized as we'd prefer not to expose the value the user. This is not for security reasons, but more because it has no value outside of the router context.
2. Converts all Error construction into builders. The apollo_id setter is private so we are forced to avoid using the constructor.

Other minor, but notable changes:

• apollo.router.operations.error measurements with the _entity path will now emit using _entity path rather than being replaced with the entity's name. This is to prevent double counting when the error counting migration is introduced in part 3. We will attempt to fix this behavior in a fast follow.
• Removes Default trait from Error to force a random apollo_id to be generated
• Makes extension_code no longer required when building an Error as many places weren't setting one with the constructor. We can revisit making it required once all of those places have proper error codes.

Part 2 of a split from https://github.com/apollographql/router/pull/7357. Part 1 can be found here: https://github.com/apollographql/router/pull/7699

---

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• [x] Changes are compatible[^1]
• [ ] Documentation[^2] completed
• [ ] Performance impact assessed and acceptable
• [ ] Metrics and logs are added[^3] and documented
• Tests added and passing[^4]
  • [ ] Unit Tests
  • [ ] Integration Tests
  • [ ] Manual Tests

Exceptions

Note any exceptions here

Notes

[^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: A lot of (if not most) features benefit from built-in observability and debug-level logs. Please read this guidance on metrics best-practices. [^4]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions.