To make link to changelogs clickable

<!-- Provide a general summary of your proposed changes in the Title field above -->

### Description
Outdated path to in-repo changelog. Removed whitespace as well.

### Checklist
<!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once)

-->

This pull request is:

- [x] A documentation / typographical error fix
	- Good to go, no issue or tests are needed
- [ ] A short code fix
	- please include the issue number, and create an issue if none exists, which
	  must include a complete example of the issue.  one line code fixes without an
	  issue and demonstration will not be accepted.
	- Please include: `Fixes: #<issue number>` in the commit message
	- please include tests.   one line code fixes without tests will not be accepted.
- [ ] A new feature implementation
	- please include the issue number, and create an issue if none exists, which must
	  include a complete example of how the feature would look.
	- Please include: `Fixes: #<issue number>` in the commit message
	- please include tests.

**Have a nice day!**

Closes: #5560
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5560
Pull-request-sha: f69e6adbe85997c88cb1c6e6c564cefdbc1c874a

Change-Id: If047c0fd4933ba09af5e3649fb8de874b886e854

but puts the changelog in a more data driven format, so that we
can begin linking version directives with them as well
as with migration documents, once those are also moved into sphinx.

- build a new Sphinx extension that allows dialect info
to be entered as directives which is then rendered consistently
throughout all dialect/dbapi sections
- break out the "empty_strings" requirement for oracle test

- begin consolidating docs for dialects to be more self contained
- add a separate section for "external" dialects
- not sure how we're going to go with this yet.

    that works in terms of the "impl" type by default.
    This is a behavioral change for those TypeDecorator
    classes that specify a custom __init__ method; those
    types will need to re-define __repr__() if they need
    __repr__() to provide a faithful constructor representation.
    [ticket:2594]

    "tuple" rows that contain
    types which aren't hashable, by setting the flag
    "hashable=False" on the corresponding TypeEngine object
    in use.  Custom types that return unhashable types
    (typically lists) can set this flag to False.
    [ticket:2592]
  - [bug] Applying a column expression to a select
    statement using a label with or without other
    modifying constructs will no longer "target" that
    expression to the underlying Column; this affects
    ORM operations that rely upon Column targeting
    in order to retrieve results.  That is, a query
    like query(User.id, User.id.label('foo')) will now
    track the value of each "User.id" expression separately
    instead of munging them together.  It is not expected
    that any users will be impacted by this; however,
    a usage that uses select() in conjunction with
    query.from_statement() and attempts to load fully
    composed ORM entities may not function as expected
    if the select() named Column objects with arbitrary
    .label() names, as these will no longer target to
    the Column objects mapped by that entity.
    [ticket:2591]

    to help with generative building.  Also slight adjustment
    regarding how SS "correlates" columns; the new methodology
    no longer applies meaning to the underlying
    Table column being selected.  This improves
    some fairly esoteric situations, and the logic
    that was there didn't seem to have any purpose.
  - [feature] Some support for auto-rendering of a
    relationship join condition based on the mapped
    attribute, with usage of core SQL constructs.
    E.g. select([SomeClass]).where(SomeClass.somerelationship)
    would render SELECT from "someclass" and use the
    primaryjoin of "somerelationship" as the WHERE
    clause.   This changes the previous meaning
    of "SomeClass.somerelationship" when used in a
    core SQL context; previously, it would "resolve"
    to the parent selectable, which wasn't generally
    useful.  Related to [ticket:2245].

    mapped classes allows that unmapped classes
    can be specified for instance- and mapper-events.
    The established events will be automatically
    set up on subclasses of that class when the
    propagate=True flag is passed, and the
    events will be set up for that class itself
    if and when it is ultimately mapped.
    [ticket:2585]

  - [bug] The instrumentation events class_instrument(),
    class_uninstrument(), and attribute_instrument()
    will now fire off only for descendant classes
    of the class assigned to listen().  Previously,
    an event listener would be assigned to listen
    for all classes in all cases regardless of the
    "target" argument passed.  [ticket:2590]