Refactored qs.add_q() and utils/tree.py

The sql/query.py add_q method did a lot of where/having tree hacking to
get complex queries to work correctly. The logic was refactored so that
it should be simpler to understand. The new logic should also produce
leaner WHERE conditions.

The changes cascade somewhat, as some other parts of Django (like
add_filter() and WhereNode) expect boolean trees in certain format or
they fail to work. So to fix the add_q() one must fix utils/tree.py,
some things in add_filter(), WhereNode and so on.

This commit also fixed add_filter to see negate clauses up the path.
A query like .exclude(Q(reversefk__in=a_list)) didn't work similarly to
.filter(~Q(reversefk__in=a_list)). The reason for this is that only
the immediate parent negate clauses were seen by add_filter, and thus a
tree like AND: (NOT AND: (AND: condition)) will not be handled
correctly, as there is one intermediary AND node in the tree. The
example tree is generated by .exclude(~Q(reversefk__in=a_list)).

Still, aggregation lost connectors in OR cases, and F() objects and
aggregates in same filter clause caused GROUP BY problems on some
databases.

Fixed #17600, fixed #13198, fixed #17025, fixed #17000, fixed #11293.
Fixed #20036 -- Improved GEOS version string parsing

Thanks chikiro.spam at gmail.com for the report.
Fixed failing aggregation tests on MySQL
Made atomic usable when autocommit is off.

Thanks Anssi for haggling until I implemented this.

This change alleviates the need for atomic_if_autocommit. When
autocommit is disabled for a database, atomic will simply create and
release savepoints, and not commit anything. This honors the contract of
not doing any transaction management.

This change also makes the hack to allow using atomic within the legacy
transaction management redundant.

None of the above will work with SQLite, because of a flaw in the design
of the sqlite3 library. This is a known limitation that cannot be lifted
without unacceptable side effects eg. triggering arbitrary commits.
Improved recovery when the connection is closed in an atomic block.
Proof-read and adjusted the transactions docs.
Fixed an erroneous import in example code.
Fix #20022: Correctly handle prefixes with url-unsafe characters in reverse().
Merge pull request #900 from bmispelon/ticket-20022

Fix #20022: Correctly handle prefixes with url-unsafe characters in reverse()
Merge pull request #900 from bmispelon/ticket-20022

Fix #20022: Correctly handle prefixes with url-unsafe characters in reverse()
Fixed #20032 -- Documented how to simulate the absence of a setting

Thanks Ram Rachum for the report.
Began implementing a shared set of test models to speed up tests.
Merge branch 'master' of github.com:django/django
Fixed #16649 -- Refactored save_base logic

Model.save() will use UPDATE - if not updated - INSERT instead of
SELECT - if found UPDATE else INSERT. This should save a query when
updating, but will cost a little when inserting model with PK set.

Also fixed #17341 -- made sure .save() commits transactions only after
the whole model has been saved. This wasn't the case in model
inheritance situations.

The save_base implementation was refactored into multiple methods.
A typical chain for inherited save is:
save_base()
    _save_parents(self)
        for each parent:
            _save_parents(parent)
            _save_table(parent)
    _save_table(self)
Fixed #20039 -- Fixed has_changed form detection for required TypedChoiceFields

Thanks Florian Apolloner for the report and the review.
Also fixes #19643.
Updated release instructions to account for website automation.
Add a specific error message for URLValidator
Fixed #17051 -- Removed some 'invalid' field error messages

When the 'invalid' error message is set at field level, it masks
the error message raised by the validator, if any.
Deprecated django.views.defaults.shortcut.
Fixed #17502 -- Made joining in inheritance cases consistent

The original problem was that when filtering two levels up in
inheritance chain, Django optimized the join generation so that the
middle model was skipped. But then Django generated joins from top
to middle to bottom for SELECT clause, and thus there was one extra
join (top->middle->bottom + top -> bottom).

This case is fixed in master as the filtering optimization is gone.
This has the side effect that in some cases there is still extra join
if the SELECT clause doesn't contain anything from middle or bottom.