Support/documentation for .NET Core debugging & hot reload workflows in Docker

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

I have a large-ish project with a dotnet backend, typescript frontend, redis, db etc - so naturally I'm going to reach for a Docker Compose stack. This works fairly well, except that as far as I can tell it's not possible to cleanly support debugging *and* hot reload in this scenario. I can either:
- Disable hot reload, and use a docker attach debugging config. This works great, except as the project grows I end up spending significant time waiting on builds for minor changes, especially with multiple projects depending on each other.
- Use hot reload, and give up on debugging. Maybe I'm missing something, but all attempts to attach give a "Attaching a .NET debugger to this process is not allowed because code changes have been applied. The process must be restarted to allow debugging." error. Ideally, I'd run a preLaunch task to force a full restart, but the only way I've found to do that is "press ctrl-r" which I can't easily do to a running docker container.

I've searched the docs and Google and haven't seen anything relating to this situation, but I can't imagine I'm the only one using dotnet core as one piece of a larger full-stack context. I think some additional docs around running dotnet in docker, and what's possible/not possible might be warranted. The dev experience with debugger attaching in general is really good, I feel like this is my last blocker to the ideal workflow.

### Describe the solution you'd like

I think there's a few possible fixes here:
- Automatically restart fully when a debugger is attached, if there are hot changes applied. This seems like the most obvious, so I assume it's hard in some way.
- Support debugging when there are hot changes
- Support an alternate method to request a full reload than a keyboard shortcut that presumes you're running dotnet in a standard terminal context.

### Additional context

A higher-level fix would be faster non-hot-reload builds - I'm not entirely clear what's taking so long in the first place. Is there a way to profile builds that my Googling hasn't surfaced?