text: Title: [FEATURE] More control over explicit test example sources
  Body: ### Is your feature request related to a problem? Please describe
  
  Right now if OpenAPI endpoint has an example under `requestBody` AND request schema has an example value for each field, Schemathesis generates 2 separate requests with different payloads but the same request parameters. This is problematic for endpoints that create resources and accept resource IDs via request parameters, for example:
  ```
  POST /book/{book_id}
  ```
  
  because the 2nd request typically fails to create the resource due to the ID clash (that is part of the request path and doesn't change from example to example).
  
  ### Describe the solution you'd like
  
  Ideally, something like this might take care of a wide range of needs:
  
  - New CLI flag `--explicit-example-count` with values:
      - `single` - at most one explicit request per operation may be performed
      - `multiple` (default) - more than one request per operation may be performed
  - New CLI flag `--explicit-example-source` with values:
    - `all`
    - `operation` - only examples defined under operation's `requestBody > content > {type} > example/examples` are used
    - `schema` - only example(s) constructed from the operation's request schema's individual field examples (not sure if more than one example can be constructed from the schema definition)
  
  This approach can be later extended to allow filtering by example name when using [`examples` with named values](https://swagger.io/specification/#media-type-object).
  
  ### Describe alternatives you've considered
  
  1. Removing either operation example or field example
      - Not ideal option as both example types typically play role when rendering the API docs from OpenAPI schema. If possible we'd like to keep both field-level examples and operation-level examples
  2. Use hooks
      - Could work but would significantly increase the complexity of the API testing. Currently we rely on the "create" operation test to set up test data that is later used by "read", "update" and "delete" operation tests. If we started using hooks to delete each created record after the test case completed, we'd then also need to start setting up the test data for "read", "update" and "delete"operation tests.
  
  