This is really two non-trivial changes. I've broken them up into multiple commits to (hopefully) make it easier to review.

1. The first three commits are making the existing field checks (other than field deletion) support extensions.
2. The subsequent/final two commits are adding checks for extension deletion.

The vast majority of changed lines are test data and test expectations (~1300 out of 1600 LOC). They are in their own commits (the third and fifth), in case you preferred focus a review on the other changes.

For the latter, since extensions are not defined in their containing message, they represent elements that a FILE check must verify aren't changed/deleted. A PACKAGE check allows them to move between files but not be changed/moved otherwise. These rules effectively consider the "identity" of the extension to be its fully-qualified name.

But all of the other checks assume the field's identity is its containing message plus number. That happens to be true of extensions, too: they can be uniquely identified by both fully-qualified name and by containing message + tag number.

The thing in here that might be a little odd is the FIELD_SAME_NAME check: it checks the fully-qualified name for extensions. So if you did rename an extension (or move it to a different package or nest it in a different message), you'll get a FIELD_SAME_NAME violation using just WIRE_JSON category. But you'll get that error plus an EXTENSION_NO_DELETE or PACKAGE_EXTENSION_NO_DELETE violation if using FILE or PACKAGE category. Is that weird?