Add ability to rename nodes

[joeyballentine]

I'm not super thrilled with the way i ended up doing this (in regard to the text input being in the menu) but it was the easiest way.

[RunDevelopment]

I don't think the UX with renaming like that is too bad. There are just a few things that need a bit more polish:

1. Clicking on Rename, then closing the context menu (e.g. by clicking elsewhere), and then opening the context menu again will still show the text box for the name. Closing the context menu should switch back the button IMO.
2. Focus and default text. I think then clicking on Rename, the text box should be (1) filled with the current node name (nickname or schema name), (2) focused (so the user can start typing), and (3) have all text selected (so the user can overwrite the current name without having to select all text manually). Basically, I want to behave like renaming a variable in VSCode.
3. The text box isn't the same height as the Rename button, which awkwardly moves the below elements down 2px. Please make them the same height.

[RunDevelopment]

Sorry, I didn't mean to approve.

[joeyballentine]

1. I'm not really sure how to accomplish that. The way that the menu hook is set up makes it really difficult to hook into any part of the life cycle of the menu from the content
2. I tried this, but it doesn't seem possible. Something about chakras inputs makes .focus()ing on a ref set to the input not work.

[RunDevelopment]

Okay, I can make the text input be focused and selected, but it's still not good enough. Chakra reaaally messes with focus in ways that I don't understand. Even if the text box is focused, simply hovering over another menu item causes it to lose focus.

I honestly think we need a different input method. I can think of 2 alternatives:

1. The WYSIWYG approach: double-click on the name of a node in the node header, and it will transform into a text box where you can edit the name.
2. Same as VSCode: show a little text box near the name of the node where the user can change the name.

Approach 1 is intuitive, but it (1) changes the meaning of double-clicking a node (not a problem IMO) and (2) has the accessibility problem that the size of the text in the text box depends on the zoom level.

Approach 2 has none of these issues, but might be harder to implement, I'm not sure.

What do you think?

[joeyballentine]

Approach 1 is what I initially tried but I had some trouble getting it to work, but I could try again I suppose

[joeyballentine]

[RunDevelopment]

Instead of adding review comments, I made you a PR with what I would have changed. Please test it to see whether you like the behavior. #2752