Make types on AdmissionRequest and AdmissionResponse public

[clux]

Was making writing serde-less unit tests for admission controller input more difficult then they had to
be. Oversight that it was left private. See #976

[clux]

There is actually one slight downside to doing this though... By making these types pub, it is easier for users to construct invalid AdmissionResponse types in actual admission controller code whereas the builder flow would force the the logic to preserve the types field throughout when moving through the flow:

AdmissionReview input -> AdmissionRequest via TryInto -> AdmissionResponse via From/::invalid -> AdmissionReview via ::into_review

The TryInto and From impls preserves the types.

However, leaving them private means people can only unit test AdmissionReview with serde. Is that OK?
I don't think it is. While having tests in raw json sends a clear signal that this is a fixture and the data is verbatim from the apiserver, it also makes it awkward to obtain and distinguish between test cases when the user wants to cover all the bases manually. Maybe the solution here is more documentation on the intended flow 🤔

[codecov-commenter]

Codecov Report

Merging #977 (9f91581) into master (050bf9d) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #977      +/-   ##
==========================================
+ Coverage   72.35%   72.37%   +0.02%     
==========================================
  Files          64       64              
  Lines        4438     4438              
==========================================
+ Hits         3211     3212       +1     
+ Misses       1227     1226       -1     

Impacted Files	Coverage Δ
kube-core/src/admission.rs	61.11% <ø> (ø)
kube-runtime/src/wait.rs	71.69% <0.00%> (+1.88%)	⬆️

[clux]

Have added a little more documentation on the admission flow, I think it's actually pretty good already. If people wishes to construct the types manually in controllers then it's going against what the documentation says (which now at every step mentions the main path). The documentation does not mention manually constructing types at all.

[nightkr]

I think this sounds OK, we're already exposing all of K8s' usual objects in all their gory detail (via k8s-openapi).