Box a large runtime error in response to clippy

[clux]

Fixes a result_large_err clippy lint in runtime by boxing an the controller::Error for #1879. This does not generally break anything for error policies. None of my controllers have been affected. Modified an example to show this user defined error types round trip the same.

We generally discourage interrogating the internal reason for reconciliation which is the main thing this error allows you to do. However, people might in advanced use cases hit this, e.g. npmp / k8s-insider-agent from a code search.

Because of this, if we decide this is worth it, it would be a breaking change, and have applied a changelog-change label.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.9%. Comparing base (14b5010) to head (bdfccec).
⚠️ Report is 52 commits behind head on main.

Files with missing lines	Patch %	Lines
kube-runtime/src/controller/mod.rs	0.0%	4 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1880     +/-   ##
=======================================
+ Coverage   75.9%   75.9%   +0.1%     
=======================================
  Files         85      85             
  Lines       8237    8238      +1     
=======================================
+ Hits        6244    6248      +4     
+ Misses      1993    1990      -3     

Files with missing lines	Coverage Δ
kube-runtime/src/controller/mod.rs	31.5% <0.0%> (-0.1%)	⬇️

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[clux]

Have done a bit of research on this, and it might still break some people, and clarified the body. It still seems like the a good way forward to me, but soliciting some feedback if people have time.

EDIT: fixing this in a non-breaking way for now. Probably not worth rushing a breaking change for a small memory optimization.

[nightkr]

Ah damn, this would've made sense to get in for 3.0.0. Honestly not sure how to handle this, as-is it's still technically breaking even if it's pretty unlikely to cause much trouble...

[clux]

yeah, i wasn't sure, whether it was a good idea to make a breaking change for it. but having looked more, it's unlikely to be an error users touch often. i'll schedule it for 4.0