Add methods for vessel-wide PartModule lookups

[siimav]

Adds the vessel-level equivalent of the existing per-part FindModuleImplementingFast<T>() helpers. Stock Vessel.FindPartModuleImplementing<T>() / FindPartModulesImplementing<T>() walk every module of every part on every call and cache nothing.

New extension methods on Vessel:

• FindPartModuleImplementingFast<T>()
• HasPartModuleImplementingFast<T>()
• FindPartModulesImplementingReadOnly<T>()

Results are cached per vessel and per type — including "there is no such module on this vessel", the expensive case stock never memoizes. The cache is a component on the vessel GameObject, so it can't outlive the vessel and needs no static registry. It is invalidated by:

• GameEvents.onVesselStandardModification,
• a vessel.parts.Count check on every access, for the paths that mutate vessel.parts
  without firing anything (ProtoVessel.Load() and friends),
• an always-on Part.ClearModuleReferenceCache() postfix, which stock calls from every
  PartModuleList mutator, for modules added/removed at runtime.

Second commit converts AsteroidAndCometDrillCache to use it. IsSituationValid() (called every OnUpdate) and GetAttachedPotato() no longer fall back to a full vessel scan when the ModuleResourceHarvester cache they previously piggybacked on is stale or missing, and the drill part no longer needs a harvester module at all.

This only pays off for call sites polled repeatedly between vessel modifications; a lookup made from an onVesselWasModified handler is always cold and gains nothing. So at a glance there doesn't appear to be good other candidates for using the new Fast methods in stock code.

For testing I have used the AsteroidAndCometDrillCache patch and had validation in code that compared the results against fresh part and partmodule loops. Slipping that in required some rather ugly code changes so probably best not to push those.