updates post vmware_rest release 4.0.0

[mikemorency]

SUMMARY

These are changes I had to make to succesfully generate content in vmware.vmware_rest release 4.0.0. It included a new openapi spec, which introduced some new data types (corresponding to existing or new modules).

Additionally, i had to update the asyncio initialization for python 3.12. The previous was of getting a loop has been deprecated. The method included in this PR passed python 3.8 + sanity checks

ISSUE TYPE

• Feature Pull Request

COMPONENT NAME

generate_cloud_modules
vmware_rest

ADDITIONAL INFORMATION

Related: ansible-collections/vmware.vmware_rest#511

[mariolenz]

ATM I don't feel able to approve this because I'm not 100% sure that I understand the changes.

But maybe @anna-savina, @mikemorency, @prabinovRedhat or @shellymiron have something to say about this. They've contributed to vmware.vmware_rest recently and, at the end of the day, the idea is to generate this collection and not do manual changes. So maybe they have some useful insights or comments on this.

[mikemorency]

its been awhile, but heres the reason for different changes:

1. The API spec introduced a few new resources that were not automatically mapping to the appropriate ansible resources. I had to add those new mapping
2. I made next_version a static value. We dont increment that in vmware_rest so having it be static makes things easier. I cant remember if this was done because the auto-generator was incrementing the version in modules and thus breaking things or if it was just like an extra thing to remember as an input when generating content
3. I had to update how ayncio is being called to comply with python3.11 lint/sanity tests. The old way of using asyncio was deprecated and stopped working with 3.11. The new way requires python3.6, but so do modern versions of ansible (which is all vmware_rest claims to support)