New option to create consts for ENUM values

Const values are a part of the draft-06 JSONSchema spec which we are using here alongside ENUMs to provide a bit of additional context.

{
    "$schema": "http://json-schema.org/draft-06/schema#",
    "enum": [
        "VALUE_0",
        0,
        "VALUE_1",
        1,
        "VALUE_2",
        2,
        "VALUE_3",
        3
    ],
    "oneOf": [
        {"const": "VALUE_0", "description": "Zero"},
        {"const": "VALUE_1", "description": "One"},
        {"const": "VALUE_2", "description": "Two"},
        {"const": "VALUE_3", "description": "Three"},
        {"const": 0, "description": "Zero"},
        {"const": 1, "description": "One"},
        {"const": 2, "description": "Two"},
        {"const": 3, "description": "Three"}
    ]
}

Functionally this is no different from using straight ENUMs, but it does allow us to include code comments from the original proto files in the description fields.

This functionality is controlled with two new proto options.

Correcting the spelling of "extension"

The file option "extension" was spelled incorrectly. This release fixes that (hopefully before anyone actually used that new proto option).

Thanks @Yowgf for pointing this out!

Custom proto options

This release introduces some more custom proto options which allow fine-grained control over the generators behaviour.

See README.md for details and examples.

Changing default file extention

As @grant points out, .json makes a more sensible choice for the generated schema files.

This version changes the default, but also introduces an option allowing users to specify whatever file extention they prefer (see README.md).

Updating to the new Google protobuf repo

The old one was deprecated and giving compile-time warnings.

Rendering google.protobuf.Struct properly

As pointed out by @grant this should generate an OBJECT.

Using $ref across the board

This release brings some bigger changes. Functinoally the schemas will perform the same, but structurally they may be quite different:

• Previously most nested messages were reproduced inline. Now their schemas are generated and added to the list of definitions, linked to using a $ref. This means that you will now know exactly which proto message your schema components were generated from.
• The root schema is also a $ref now, which facilitates edge-cases like recursive self-references (yes this is a thing)

Renamed field-options

I've secured an extention to our options range, which means that we can use it for things other than just FieldOptions (MessageOptions, FileOptions, EnumOptions etc). These will be used to offer fine-grained control over the schema generated behaviour.

    string hidden1  = 3 [(protoc.gen.jsonschema.field_options).ignore = true];

  string query = 1 [(protoc.gen.jsonschema.field_options).required = true];

Custom FieldOptions

We now have an officially registered custom options number, and have built it into options.proto.

• "ignore": Fields tagged with this will be skipped / omitted from generated schemas
• "required": Fields tagged with this will be marked as "required" in generated schemas

Another bug with OneOf and AllFieldsRequired

Thanks @NoobMaster-96 for helping to test this