Add branch management commands

[vpetrovykh]

We need to update the CLI in order to make EdgeDB branches usable for developers (see RFC 1025).

We need to add the following commands:

• edgedb branch create

  It must have the --from <oldname> option. If this option is omitted the current branch specified in the edgedb.auto.toml file is used as the "from" branch. After the branch is created, the edgedb.auto.toml file is updated to use the new branch as the connection default.

  It must have the --empty option. If specified, this is equivalent to running create empty branch <newname> DDL command.

  It should have the --copy-data option. By default a new branch copies schema only.

• edgedb branch drop is identical to the old edgedb database drop command.

• edgedb branch wipe is identical to the old edgedb database wipe command.

• edgedb branch switch command for updating edgedb.auto.toml and
  switching between different EdgeDB branches.

• edgedb branch rename <oldname> <newname> command in order to be able to rename branches.

• edgedb migration format --upgrade command to update the migration file names tot he new format. If our CLI tools detect that the migration files are using the old format they should suggest running edgedb migration format --upgrade in order to proceed with any other migration or branch commands.

• edgedb branch rebase to rebase one branch on top of another. This is how rebasing "feature" on top of "main" branch would work. Our CLI tools may need to first clone the "main" branch with the data into a "temp" branch. Then we can introspect the migration histories of "temp" and "feature" branches so that we can establish where they diverge. Take all the divergent migrations from the "feature" branch and apply them to the "temp" branch. If the operation is successful, drop the "feature" branch and rename "temp" to "feature". We now have successfully rebased "feature" branch on top of "main".

• edgedb branch merge command to perform a fast-forward merge by copying the migration history and applying migrations.

[diksipav]

Form the first read I can only add:

1. what happens if user deletesedgedb.auto.toml, is that safe?
2. edgedb branch rename <oldname> <newname> if we want to rename current branch I think we should omit oldname (I also like github's -m, but I guess rename is better in our case since we don't use many abbrevations)
3. A new project should ask the user for the branch name defaulting to "main". does it make sense that main db branch can be diff from the main VCS branch?
4. Eventually we need to update our js create tools with edgedb.auto.toml and add it automatically to .gitignore.

[vpetrovykh]

1. what happens if user deletesedgedb.auto.toml, is that safe?

You'd lose all the mapping between git branches and EdgeDB branches and the default branch to connect to will be whatever is in edgedb.toml (usually just "main"). This is annoying to restore, but relatively safe.

2. edgedb branch rename <oldname> <newname> if we want to rename current branch I think we should omit oldname (I also like github's -m, but I guess rename is better in our case since we don't use many abbrevations)

Omitting the oldname in renaming is IMO too much magic. The current branch may not be obvious/visible. I was following the logic of OS mv (or rename) command.

3. A new project should ask the user for the branch name defaulting to "main". does it make sense that main db branch can be diff from the main VCS branch?

Currently our default branch is just "edgedb" for all local projects and I think we default to project name for cloud. You are likely to have more VCS branches than database branches because not everything involves a schema change.

4. Eventually we need to update our js create tools with edgedb.auto.toml and add it automatically to .gitignore.

Our tools should check .gitignore and offer to add edgedb.auto.toml to it, but this should never be a silent operation, this should be an easy opt-in (just answering a y/n prompt or something like that).