feat(cloudflare): Infer types correctly in workflows, handlers and DOs

[JPeer264]

closes #18294

Problem

In #18064 we fixed that any Cloudflare compatible app can be passed and the original types were passed (e.g. Hono). This caused a problem with the environment variables, as they were not inferred correctly. Those are two scenarios which should work:

1. That we can wrap any app (e.g. Hono), which is compatible with Cloudflare and ensure the types are there (actually what fix(cloudflare): Ensure types for cloudflare handlers #18064 should have solved - but it introduced a bug)
2. The optionCallback infers the correct types, based on the handler it was given

Solution

To ensure now that types are passed through (for e.g. Hono) and the all necessary types are inferred correctly, there is now only one source of truth for the types in the generics.

So instead of having withSentry<Env = unknown, ..., T extends ExportedHandler<Env>>() it is now withSentry<Handler extends ExportedHandler<Env>> and whenever we would need the types, we actively infer them inside the function with InferEnv<Env>. With that approach we make sure both scenarios work properly

The tests are now using the correct types as well (that was not the case and was the main issue why #18064 went through)

---

This is now also true for .instrumentDurableObjectWithSentry() and .instrumentWorkflowWithSentry().

[andreiborza]

As discussed offline, this PR introduces breaking changes to the way generics are used and we can thus not merge this in this major.

Let's add this to the v11 milestone and fix it then, for now document what users have to do to get correct types.