Return error from watcher when kinds do not support watch

[clux]

A quick fix for #1092. This should just cause the watcher to spin infinitely (like in the case where the crd isn't installed and people try to watch there). It's not 100% ideal, as an explicit crash might be better for many users to be seen early.

sidenote: A previously considered alternative we have thought about is to look at having watcher separate between recoverable and irrecoverable errors (e.g. a resource not being installed or support watch). The problem between trying to do that separation is that those classes are not static; irrecoverably may become recoverable due to external factors (a crd might become installed, a crd might be upgraded to support watch in a new release).

This PR avoids crashing user code without their knowledge (something users generally hate), but it will also potentially not work, get successfully deployed (replacing an older version in a rolling upgrade due to no crashloop), but will just spin-error continuously without actually doing anything. Then again, it's not like an earlier version will have worked with watch, because if a resource does not support watch, it did not support watch before we started error handling.

Passing an error here does give the whole system a (slim) chance to fix itself if a simultaneous upgrade to a resource (adding watch support for the resource) gets deployed. So it's in-line with standard "eventual consistency" ideals. The spin-lock problem is also somewhat mitigated with backoff support.

[codecov-commenter]

Codecov Report

Merging #1101 (50fcf74) into main (edd1121) will decrease coverage by 0.00%.
The diff coverage is 80.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1101      +/-   ##
==========================================
- Coverage   72.66%   72.65%   -0.01%     
==========================================
  Files          65       65              
  Lines        4832     4835       +3     
==========================================
+ Hits         3511     3513       +2     
- Misses       1321     1322       +1     

Impacted Files	Coverage Δ
kube-runtime/src/watcher.rs	51.25% <80.00%> (+0.60%)	⬆️

[clux]

Considered writing a test for this, didn't feel super helpful. Behaviour can be verified in a cluster with pod/node-metrics via:

GROUP=metrics.k8s.io VERSION=v1beta1 KIND=NodeMetrics cargo run --example dynamic_watcher

which unwraped before and now prints the error and exits. so this should be a straight improvement in the standard watcher case where people use the normal TryStream pattern.