Normalise name and description fields with language codes

[odscjames]

Some earlier versions of the extensions did not have language codes, so that currently we get

"bids": {
            "versions": {
                "v1.1.1": {
                    "name": "Bid statistics and details",
                    "description": "Allowing bid statistics, and detailed bid information to be represented."
                },
                "v1.1": {
                    "name": "Bid statistics and details",
                    "description": "Allowing bid statistics, and detailed bid information to be represented."
                },
                "v1.1.3": {
                    "name": {
                        "en": "Bid statistics and details"
                    },
                    "description": {
                        "en": "Allowing bid statistics, and detailed bid information to be represented."
                    }
                },

The output of this package should be normalized so there is always a language code there.

[jpmckinney]

One implementation option would be to add a method to ExtensionVersion in extension_registry.py to normalize the metadata in extension.json. If so, in terms of API, I think it makes sense for the existing .metadata() method to return normalized output (so that users don't need to know that metadata format changed across time), and to perhaps add a .raw_metadata() method to access the original metadata.

[odscjames]

I have done this as a seperate def for now, with a note saying it could be pushed upstream.

I agree it would be good to, but there is a slight problem to overcome first in that the code upstream will always download the file, or use it's in memory cache. In this package we store files to disk, and I've already got it so that in some cases it re-uses the files on disk between runs, thus saving downloads and time.

There was a comment elsewhere about extracting code upstream - I'm sure it can be done with a little thought about the API design. Will bear this case in mind.

[jpmckinney]

For sure - it will likely be simpler to consider API changes once this repo's needs are fleshed out through further implementation :)