[WIP] Allow filtering of Role Assignment lists by ansible_id

[AlanCoding]

Previously, we added ansible_id and user_ansible_id as strictly writable fields (also same for team) for assigning a role to a user.

This bakes this relationship into the models so that a client can use it to filter the entries, like:

{
    "count": 3,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 1,
            "url": "/api/v1/role_user_assignments/1/",
            "related": {
                "created_by": "/api/v1/users/1/",
                "role_definition": "/api/v1/role_definitions/1/",
                "user": "/api/v1/users/5/",
                "content_object": "/api/v1/organizations/1/"
            },
            "summary_fields": {
                "created_by": {
                    "id": 1,
                    "username": "_system",
                    "first_name": "",
                    "last_name": ""
                },
                "resource": {
                    "ansible_id": "c2b44764-3deb-4daf-a6cc-d2476cab6fbc",
                    "resource_type": "shared.organization"
                },
                "role_definition": {
                    "id": 1,
                    "name": "organization-admin",
                    "description": "",
                    "managed": true
                },
                "user": {
                    "id": 5,
                    "username": "org_admin",
                    "first_name": "",
                    "last_name": ""
                },
                "content_object": {
                    "id": 1,
                    "name": "AWX_community"
                }
            },
            "created": "2024-05-08T20:47:54.023629Z",
            "created_by": 1,
            "content_type": "shared.organization",
            "object_id": "1",
            "resource": "c2b44764-3deb-4daf-a6cc-d2476cab6fbc",
            "role_definition": 1,
            "user": 5,

Filtering:

http://127.0.0.1:8000/api/v1/role_user_assignments/?resource__ansible_id=c2b44764-3deb-4daf-a6cc-d2476cab6fbc

And again, the writable fields are:

TODO: the user and team fields should be blank/null, and the screenshot shows that's not working.

So we will move away from object_ansible_id (which is a UUID/string field) and towards the resource field which is relational. With this, more things will "just work".

This was not done before, because generalized filtering wasn't implemented at that time, and I thought "resource" was confusing. But now this PR matches the already-implemented general filtering. FYI @newswangerd . In other words, compare to:

http://127.0.0.1:8000/api/v1/organizations/?resource__ansible_id=c2b44764-3deb-4daf-a6cc-d2476cab6fbc

This URL discovers the object that the assignment applies to. Importantly, for the API contract, it uses the same query string.

[AlanCoding]

Another TODO: Write migration to add the resource link on role assignments that already list

TODO of slightly similar scope: change migration utility give_permission to associate the resource if it exists as well.

[AlanCoding]

TODO: #385 server error from not separating lookup kwargs from default kwargs

[AlanCoding]

From ansible/galaxy_ng#2157, we see that galaxy-ng uses content_object to reference the related object by its ansible_id. That is a potential alternative for the field naming here, although it's not exactly filterable by that same contract.

[john-westcott-iv]

@AlanCoding is this still something we want to pursue?