Stop treating schema warnings as errors

[czechboy0]

Motivation

In #130, we introduced extra validation by calling into OpenAPIKit's validate method. (It's hidden behind a feature flag, but I've been testing with it enabled.)

It looks for structural issues, such as non-unique operation ids, which would result in us generating non-compiling code anyway, so the validation helps catch these early and emit descriptive errors that adopters can use to fix their doc.

However, the method also takes a parameter strict, which defaults to true, and when enabled, it turns warnings emitted during schema parsing into errors. This part is too strict for us and was rejecting OpenAPI documents that were valid enough for our needs.

An example of a schema warning is a schema having minItems: 1 on a non-array schema. While it's not technically correct, it also doesn't impede our understanding of the non-array schema, as we never actually check what the value of minItems is. That's why these are just warnings, not errors, so we should stop promoting them to fatal errors that block an adopter from generating code.

Modifications

This PR flips the strict parameter to false. This doesn't make us miss out on these warnings, as recently (in #174), we started forwarding these schema warnings into generator diagnostics, so the adopter will see them still, and can address them on their own schedule.

Result

Now documents with only schema warnings aren't rejected by the generator anymore.

Test Plan

Added a unit test of the broken-out validateDoc function, ensures that a schema with warnings doesn't trip it up anymore.