Further consolidate and expand resource methods

[shawkins]

Is your task related to a problem? Please describe

There are quite a few places where getting a hold of a Resource makes sense, we should do this as consistently as possible.

Describe the solution you'd like

Instead of Itemable.withItem, we'll use resource. Everywhere else that uses Nameable (except for pod and node metrics) could also use a resource method:

client.configMaps().resource(item) - instead of client.configMaps().withItem(item)
client.configMaps().resource(name) - instead of client.configMaps().withName(name)

For lists:

client.configMaps().resources() - instead of client.configMaps().list().getItems().stream()
client.resourceList(list).resources() - instead of client.resourceList(list).getResources()

From @manusa -
client.configMaps()...stream() or similar (vanilla or Reactive library specific return type), which might pave the way for a future async implementation
- Blocking impl: list().getItems().stream() / Multi.createFrom / Observable.create / …
- Non-blocking impl: watch/inform -> stream / reactive fwk specific streaming impl

Unfortunately inform will still be blocking. The first operation it needs to do is a list. A list could be non-blocking, but the result parsing will be tricky as non-blocking as the root object is a KubernetesList. A watch could be non-blocking, but you won't know when the initial add events are done.

Describe alternatives you've considered

No response

Additional context

No response