`Get Started`: rollback secion misleading

The following section from [LDB Workflow](https://github.com/iterative/ldb-resources/blob/main/documentation/Getting-started-with-LDB.md#ldb-workflow) is misleading:

> If we don't like the result and want to roll back the
changes, LDB versioning system makes it easy. All we need to roll back
to the previous dataset version is to stage it and push as a new
revision:
>
> Step | Command
> -- | --
> Stage a specific dataset version | $ ldb stage ds:numerals.v1
> Save it as the "current" version | $ ldb commit
>
> At this point, LDB holds two revisions of the dataset
"numerals", v.1 and v.2, and the former is the version that will now be
checked out by default.

Running the described sequence of commands don't do anything:

```console
$ ldb status ds:my-numerals
ds:my-numerals.v3
Num data objects: 2525
Num annotations: 2525
$ ldb stage ds:my-numerals.v2
Staged ds:my-numerals.v2 at '.'
$ ldb commit
Nothing to commit.
```

TBH, I don't fully understand what would be the output expected.

I would expect this sort of rollback to be handled in a different way, maybe by having a convention around `latest` tag and implementing `ldb tag` (supporting datasets as targets, https://github.com/iterative/ldb/issues/88) :

```console
# Current status
$ ldb status ds:my-numerals
ds: my-numerals.latest (-> ds:my-numerals.v3)
Num data objects: 2525
Num annotations: 2525
$ ldb stage ds:my-numerals --force
Staged ds: my-numerals.latest (-> ds:my-numerals.v3) at '.'
```

```console
# rollback updating latest tag
$ ldb tag latest ds:my-numerals.v2
```

```console
# Effect of rollback
$ ldb status ds:my-numerals
ds: my-numerals.latest (-> ds:my-numerals.v2)
Num data objects: 1500
Num annotations: 1500
$ ldb stage ds:my-numerals --force
Staged ds: my-numerals.latest (-> ds:my-numerals.v2) at '.'
```