`podman play kube` doesn't warn for unrecognised keys in YAML

Issue Description

Sorry for brevity, I am in a hurry as I type.

If I add an invalid key to a YAML file generated by podman generate kube, I'd like podman play kube to spit out a warning when generating the pod. E.g. so that I can't type workdir or working_dir in lieu of workingDir and then wonder why the pod isn't starting properly.

Steps to reproduce the issue

Steps to reproduce the issue

1. Take any valid YMAL file, e.g. generated by running podman generate kube on a current pod
2. Add a key to the YAML that isn't vaid k8s YAML - e.g. foo: bar at the root level.
3. podman play kube /path/to/that/file.yaml
4. podman continues on its merry way.

Describe the results you received

Describe the results you received

Describe the results you expected

e.g. Warning: key 'foo' under scope 'top-level' not understood. Ignoring

podman info output

host:
  arch: amd64
  buildahVersion: 1.24.1
...
  distribution:
    codename: bullseye
    distribution: debian
    version: "11"
...
  kernel: 5.18.0-0.deb11.4-cloud-amd64
  linkmode: dynamic
  logDriver: journald
...
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux

  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
...
version:
  APIVersion: 4.0.1
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.17.7
  OsArch: linux/amd64
  Version: 4.0.1

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

Also tested on Podman 3.4.2 under Ubuntu

I would use a later version, but trying to go to podman static so I can upgrade past what is in the repos broke my system and am yet ot have had time to fix it ;)

Additional information

It may make more sense to have this feature disabled by default - e.g. add a --verbose flag to the command to enable checking of the file.