scmutil: explicitly subclass the `Status` protocol We shouldn't have to explicitly subclass, but PyCharm has a nifty feature that puts a jump point in the gutter to navigate back and forth between the base class and subclasses (and override functions and base class functions) when there's an explicit subclassing. Additionally, PyCharm will immediately flag signature mismatches without a 40m pytype run. It was also hoped that with explicit subclassing, we would get interface checking for free. Unfortunately when I tried adding methods and fields to the Protocol class to test this theory, pytype happily accepted an assignment of the concrete class without the new field and methods, to a variable annotated with the Protocol class with them. It appears that this is what happens when explicit subclassing is used, since dropping that caused pytype to complain. By making the methods abstract here like the `mercurial.wireprototypes` classes in fd200f5bcaea, pytype will complain in that case outlined that a subclass with abstract methods (not replaced by the subclass itself) cannot be instantiated. That doesn't help with the fields. Making an `abstractproperty` likely isn't appropriate in general, because that effectively becomes a read-only property. This seems like a pretty gaping hole, but I think the benefits of explicit subclassing are worth the risk. (Though I guess it shouldn't be surprising, because a class can be both a Protocol and an implementation, so subclassing something with an empty body method doesn't really signal that it is a requirement for the subclass to implement.)