feat: allow durable objects migrations within environments

[threepointone]

We let folks define [durable_objects] under environments (in fact, we demand it), so one of the two should be true -

• Either we should verify that the shape of [durable_objects] should be the same across environments (except for DOs with script_name?)
• Or [migrations] should be defined under environments as well.

I think it should be the former, but open to suggestions.

[petebacondarwin]

What happens if you are developing a new DurableObject class, not yet on production, and you want to deploy to staging for testing? It seems that the only way is to decouple the migrations for each environment...

[petebacondarwin]

Given that we are currently sticking with "non-service environments", each environment declared in wrangler.toml results in a new Worker which can have its own Durable Object (DO) declarations. It is very reasonable to have an environment that declares a DO that is not declared in other environments - e.g. adding a new DO in staging before sending it to production, removing a redundant DO in staging before removing it from production.

Therefore I think it is right that migration should also be defined in environments rather than being only at the top level config.

To avoid backward compatibility concerns it is best to make this an "inheritable" configuration property, which means that it can be simply defined at the top level and then apply to all environments without having to redefined it for each environment.

[yerol]

Just got hit by this limitation today. Definitely a must have! I have 2 workers with 2 separate environments (dev & prod) sharing most of their code so they have to stay in the same project. 1 worker uses DO but the other one doesn't. There was no way to deploy the one without DO, unless I removed migrations definition from toml. I wish there was a way to use separate toml files for each environment/worker too.

[WalshyDev]

Hit this today too, we should definitely be supporting this per-env.
cc: @petebacondarwin @RamIdeas

I imagine others will hit this too (is this something you have ran into @jahands with your work?)