feat(db): add examples to metaschema fields

[Guaris]

Summary

This pull request introduces a new field attribute called examples in the metaschema. The examples attribute is designed to provide example values for fields in schemas. examples is an array so you can specify multiple example values for a single field.

Adding examples would like this:

kong/db/schema/typedefs.lua

typedefs.certificate = Schema.define {
    type = "string",
    custom_validator = validate_certificate,
    description = "A string representing a certificate.",
    examples = {
        "-----BEGIN CERTIFICATE-----\nYourCertificateDataHere\n-----END CERTIFICATE-----",
        "-----BEGIN CERTIFICATE-----\nAnotherCertificateDataHere\n-----END CERTIFICATE-----"
    }
}

and

typedefs.auto_timestamp_s = Schema.define {
  type = "integer",
  timestamp = true,
  auto = true,
  description = "An integer representing an automatic Unix timestamp in seconds.",
  examples = { 1633924743 }
}

But also in plugin schemas, examples help illustrate what the data is supposed to look like.
For example:
kong/plugins/response-ratelimiting/schema.lua
for redis_port

{
  redis_port = typedefs.port({
    default = 6379,
    description = "When using the `redis` policy, this property specifies the port of the Redis server.",
    examples = { 6379 }
  }),
},

or redis_password

{
  redis_password = {
    description =
      "When using the `redis` policy, this property specifies the password to connect to the Redis server.",
    type = "string",
    len_min = 0,
    referenceable = true,
    examples = { "myredispassword" }
  },
},

Why

Improved automation

We've already invested in automation for generating API specs and the plugin configuration reference. The inclusion of example fields is a natural extension of this effort in my eyes. By providing concrete examples in the Lua schemas, we can generate more informative and accurate specs/docs automatically.

Communication

Examples illustrate what data should look like, this makes it easier for people to understand the intended structure and format of fields in our schemas.

Plugins

Currently, we offer descriptions, sometimes default values in our plugin configuration reference docs. We could add examples and sometimes we do within the description field, but that information grows stale. My theory is that providing accurate examples in the schemas, and subsequently in the docs, would help users onboard with plugins.

[kikito]

We will want to backport this (the field definition, not the contents of the field) to older versions of the gateway in order to facilitate backports.