From the engines you mentioned (Godot,Unreal,Unity) the game engine itself offers the full SDK suite you need to develop games and it they are tightly integrated with the engine.
I'm most familiar with Unity so I'll speak on that. Unity itself offers the editor (can be configured), debugger, asset manager and visualizer all in the main client. Some people have built external tools on top of Unity for things like no-code game building but the vast majority of developers directly use Unity.
I think Godot is probably the most unique of the ones you listed in that it seems like the one you might can mix and match different tools together but I'm overall much less familiar with it.
OP asked about "SDK Generators for Application APIs". So my guess is like when you want tight Steam integration in your Godot/Unity/Unreal/etc game, or IAP for mobile game, it's not engine-provided, but some engine-external package/plugin/lib that's sometimes called SDK, sometimes not.
I understand these engines have their own full SDK for developing with the engine, but I'm curious about the external ecosystem/integrations/libraries. It isn't a space I'm super familiar with, but I'm interested in it, not only from the standpoint of it being an interesting technology I've never played with before, but also because I'm curious if there are similar issues in the game engine SDK space as there are in the application SDK space.
Or maybe even a whole different host of issues and practices. Not sure, that's what I'm looking into.
I'm most familiar with Unity so I'll speak on that. Unity itself offers the editor (can be configured), debugger, asset manager and visualizer all in the main client. Some people have built external tools on top of Unity for things like no-code game building but the vast majority of developers directly use Unity.
I think Godot is probably the most unique of the ones you listed in that it seems like the one you might can mix and match different tools together but I'm overall much less familiar with it.