Garden deployment editing could use a second pass

[WillEngler]

The new deployment update flow is a huge improvement over the old status quo of making a "sacrifice" garden, copying over its functions to the target garden, and deleting the new garden. But there are snags that would be nice to iron out. This ticket doesn't have firm prescriptions - this needs some design thinking before it's ready to code. Some high level pain points include:

• What is a deployment? How can we make that a more discoverable concept?
• What happens when a user wants to change the name of a function they've deployed? This is pretty awkward at the moment. (right now they need to remove that function from a garden that uses it, redeploy with a new function name, and attach that new function to the garden)
• It seems like even deployments that have errored out stay in a user's deployments tab and expose their functions to the add/remove functions dialog

[WillEngler]

Let's scope this ticket as what remains in the UGMI work. When you're ready to call that done, let's double check to make sure the sub-tickets that remain accurately cover what we'll want to pick up later. (You've already made a ticket for, eg, changing the name of deployed functions, so I suspect we're already good)