feat(sample-gen): infer implicit type and validation constraint types

[mathis-m]

Description

this close some dead ends of sample generation where no sample was generated.

• implicit any type => "string"
• and

const objectContracts = ["maxProperties", "minProperties"]
const arrayContracts = ["minItems", "maxItems"]
const numberContracts = [
  "minimum",
  "maximum",
  "exclusiveMinimum",
  "exclusiveMaximum"
]
const stringContracts = ["minLength", "maxLength"]

currently with v3.30.0:
https://petstore3.swagger.io/?url=https://gist.githubusercontent.com/mathis-m/6839105763cbe96755c4b6455c69278b/raw/543198cdd6a232a4465eac19537bb2c7805b80e9/uR3BxRNUhU.txt

I think the proper solution for this would be to default type to string if not defined. This would result in a stable behavior too and we could keep the decision to generate the using first anyOf for anyOf samples. I think this is the a spec conform sample generation logic, because it is the "most simple" case for anyOf that can emerge from such a schema.
With #7117:

Originally posted by @mathis-m in swagger-api/swagger-editor#2416 (comment)

Motivation and Context

Fixes swagger-api/swagger-editor#2416

How Has This Been Tested?

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[tim-lai]

@mathis-m PR merged! Thanks for the contribution and continued iteration!