Support type: "null" for OpenAPI 3.1 schemas (runtime + TypeNullIn30 rule)

[takayamaki]

Continuing the OpenAPI 3.1 work from #195 / #152.

OpenAPI 3.1 (via JSON Schema) adds "null" as a primitive type name.
In 3.0, nullability was expressed via the nullable keyword; type: "null" had no meaning.

This PR adds both runtime validation and version-mismatch detection for type: "null".

Runtime validation

# 3.1 document
schema:
  type: "null"
# nil → valid, "hello" → ValidateError

The accept side and the reject side live in two different validators,
because of how SchemaValidator#validator dispatches:

def validator(value, schema)
  # ...
  return nil_validator if value.nil?   # <- every nil value goes here,
                                       #    before the type dispatch below
  case schema.type
  # ...
  when 'null'
    null_type_validator                # <- only non-nil values can reach this
  # ...
end

Accepting nil

happens in the existing NilValidator, which handles all nil values regardless of schema type. It now treats schema.type == "null" as valid, exactly like the existing nullable: true path.

Rejecting everything else

happens in the new NullTypeValidator. Since nil values are routed to NilValidator before the type dispatch, any value reaching the when 'null' branch is by construction non-nil.
So NullTypeValidator unconditionally returns a validation error.
Without the new branch, type: "null" would fall through to UnspecifiedTypeValidator and accept any value.

SpecValidator rule

TypeNullIn30 walks all schemas and reports a violation when a 3.0 document uses type: "null".
Array-form types like ["string", "null"] are covered by a separate rule in a later PR.

OpenAPIParser.load(
  'spec.yaml',
  strict_specification_version: :warn,
)
# [TypeNullIn30] #/…/schema — `type: "null"` is a 3.1 addition; 3.0 documents have no such primitive

[geemus]

@takayamaki broadly I think this looks good. I guess my question would be around things like ["string", "null"]. Will this change their behavior, or would they be fine until the subsequent PR? Maybe we should at least add some basic tests here if we are deferring to capture the current state and avoid any potential regressions in the interim. What do you think?

[takayamaki]

@geemus Thank you for review!

This PR does not change behavior for array-form types like type: ["string", "null"], only type: "null".
Arrays still fall through to unspecified_type_validator as before.

Actually, I have the array-type support ready and opened it as a stacked PR:
#198

Let me know if you'd still prefer the snapshot-test approach in this PR instead.