[3.3.x][Fixes #8689] Extend the ResourceBase metadata model with an opaque JSONField

[mattiagiupponi]

refers to #8689

• New model named ExtraMetadata, this model will contain the information about the extra metadata that the resource can have
• Add searchable field for both API
  -- Api V2 search into metadata fields:
  http://localhost:8000/api/v2/resources?filter{metadata.metadata.icontains}=%22category%22:%20%22bar%22
  -- Api V1 search into metadata fields:
  http://localhost:8000/api/base/?limit=5&offset=0&metadata__category=object

NOTE: in the API v2, the icontains is required since DynamicRest is not able to parse JSON fields like Django ORM. A pull request was raised in 2020 but is unmerged since the library is not so maintained

• GeoApps, Maps and Document views fixed. In case of errors, the metadata wizard was raising only a "Unknown error", now the correct error is raised to the user
• Add in resource v2 endpoint the possibility to GET/Update/delete/add metadata to the resource
• settings.py now contains the default structure available for the metadata. This structure is validated and each resource can have its own metadata structure
• validation function named validate_extra_metadata ensure that the structure passed from form/API is the same as the one defined in the settings.py file. Is used in both API and Form
• schema validation is performed by schema library
• test coverage for new functionalities

Checklist

Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

For all pull requests:

• Confirm you have read the contribution guidelines
• You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
• Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

• There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
• The issue connected to the PR must have Labels and Milestone assigned
• PR for bug fixes and small new features are presented as a single commit
• Commit message must be in the form "[Fixes #<issue_number>] Title of the Issue"
• New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented
• This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
• This PR passes the QA checks: flake8 geonode
• Commits changing the settings, UI, existing user workflows, or adding new functionality, need to include documentation updates
• Commits adding new texts do use gettext and have updated .po / .mo files (without location infos)

Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

[mattiagiupponi]

@afabiani the PR for adding the needed validation schema for the client geoapp is available here: GeoNode/geonode-mapstore-client#783

[afabiani]

@mattiagiupponi let's port this one to master too