feat: add assert_operation_response, assert_raw_schema

[msutkowski]

This is a small proposal to add a few things to help with testing based on operationIds instead of (or along side of) schema_names. There are a few benefits to this, but the primary one is that it enforces operationId usage. Most organizations that deal with any type of code generation are going to most likely want to enforce operationIds.

I thought about just looking at the path in conn and resolving backwards with a method like assert_uses_schema, but that was a bit too 🪄 for what I wanted to achieve. (i was able to achieve this very simply by assigning the operation_id. it now supports automatic inference or manual specification)

I'm sure I've missed something here, but very open to feedback if anyone else would benefit from this 🎉

[duntonr]

This would really help in our case. Aside from operationIds, we define our spec file manually and put responses at #/components/responses/getFoo.

For JSON:API, this lets us define standard, top level attributes in the response, like type, id, links, etc and then ref to the attributes to its actual schema/model specific definition that lives at #/components/schemas/foo

[msutkowski]

@zorbash Updated to address feedback, thanks!