Inconsistent behaviour from commit() in nested db.atomic() (PostgreSQL)
Thanks, fixed.
`db.atomic()` returns either a transaction or a savepoint, depending on the nesting level.  Manually committing or rolling back a transaction starts a new transaction, but *not* for savepoints.  In PostgreSQL, it is valid to [roll back](https://www.postgresql.org/docs/current/static/sql-rollback-to.html) a savepoint multiple times, but you can only [commit once](https://www.postgresql.org/docs/current/static/sql-release-savepoint.html).

The net result of all this is inconsistent behaviour from the object returned by `db.atomic()`:

```python
class Test(Model):
    value = CharField()

    class Meta:
        database = db

db.connect()
db.drop_table(Test)
db.create_table(Test)

with db.atomic() as trans:
    Test.create(value='trans rollback')
    trans.rollback()

    Test.create(value='trans commit')
    trans.commit()  # success

    with db.atomic() as savep:
        Test.create(value='savep rollback')
        savep.rollback()

        Test.create(value='savep commit')
        # savep.commit()  # `InternalError: no such savepoint` on __exit__

for test in Test.select():
    print(test.value)
```

I believe that the object returned from `db.atomic()` should *always* behave like a transaction, where manually committing or rolling back starts a new transaction.  The code above makes it obvious that there are nested transactions, but consider a helper method that sometimes is called in a transaction and sometimes not: that method cannot manually commit.