Certificate pinning (or public key pinning) is used by many browsers for at least some sites, and by some non-browser client software. The idea is that the client (browser or otherwise) is programmed to check the certificate it receives against known properties of the legitimate certificate. For example, the client might verify that the certificate uses one of a few public keys (the current one when the client was built, and future/back-up in case rotation is needed), or that the certificate is issued by a particular CA, or similar. In extreme cases you can pin the entire leaf certificate, but that means any update or rotation will require a client update to remove the old cert and add a new future cert.
Cert (or public key) pinning is most common when the software and the server are provided by the same developer. Google pins all of their properties in Chrome. Microsoft might do the same in Edge - not sure - but they definitely do it for some other software (registration servers, I think also the default update servers). I think Firefox might do so for Mozilla properties. You'll also see it with things like apps (Twitter, for example, might use pinning in their mobile apps, though I don't know if they do). At least one fraudulent Google certificate has been detected via this mechanism.
There was an attempt to standardize a way for sites to provide their own pins to browsers, too. It was called HTTP Public Key Pinning, or HPKP, and allowed sites to specify properties of their certificates (and a mandatory backup), with an expiration, much the same way HTTP Strict Transport Security (HSTS) works. Like HSTS (and also similar to SSH), it was trust-on-first-use; any valid HTTPS response could include the header, and as long as it matched the current cert, it would be trusted. Unlike HSTS, HPKP was never widely adopted, and is now deprecated. Some browsers might be configurable to enable it - my copy of Firefox still has "security.cert_pinning.hpkp.enabled" in about:config - but it's disabled by default.
One of the features of HPKP was the ability to set a report URL. Similar to Content Security Policy (CSP) - although it seems CSP has also deprecated this - HPKP allowed specifying that the client should send reports of invalid certificates it encountered for the site. The idea was, collect information as widely as possible about potential attacks going on. If the client had a clear connection to a third-party site, they could report the fraudulent certificate there (connections to the site with the fraudulent cert being intercepted already, the attacker presumably wouldn't allow the report to pass).
There's also the EFF SSL Observatory, which monitors the certs used online. In theory this could detect unexpected certificate changes, or situations where different people see different certs.
To address your ideas #1 and #3, the problem there is that, if the connection to the server is compromised, the attacker can just modify the content that the client receives. You read a list of hashes, or check a header, and see that it matches the cert you just received... because a simple string substitution swapped out the legit cert's hash for the fraudulent one. This kind of transformation is not new; things like SSLStrip use it to re-write URLs. It would be pretty simple to make this work for the common hash algorithms and encoding formats.
To prevent that kind of attack, you need either a system that remembers the old value (this is what HPKP was aiming to do, with its duration settings), or a third party (which is hopefully reachable over a secure connection!) such as you see with Certificate Transparency (as covered in another answer).