more precise return types for 13 clone() methods

[stephengold]

This addresses issue #1676, changing the return types of 13 clone() methods to the class in which they're declared.

This is technically an API change. The most likely breakage would be if external code extended one of these classes and overrode clone() with a method returning a supertype (such as Object). That would lead to a compile-time error due to incompatible return types.

[pspeed42]

Any code calling these clone() methods directly will now also throw an error if not recompiled.

I think it's a low risk change but it could mean if there are common libraries out there that call these clone methods directly that they would need to be recompiled or they will break applications that try to upgrade. (If so then those libraries are maybe doing things wrong and I'm kind of ok with forcing that conversation.) But worth noting just the same.

[stephengold]

Worth mentioning in the release notes, assuming this gets integrated.

[stephengold]

Unless there's further discussion, I plan to integrate this in about 24 hours.

[pspeed42]

You are doing the lord's work, so to speak.

[stephengold]

I hope I don't get crucified for it!