Add support for named primary keys on SQL Server

[billschaller]

This PR adds support for named primary keys on SQL Server, and fixes 2 SQL generation tests that should generate named primary keys to do so.

[doctrinebot]

Hello,

thank you for creating this pull request. I have automatically opened an issue
on our Jira Bug Tracker for you. See the issue link:

http://www.doctrine-project.org/jira/browse/DBAL-1155

We use Jira to track the state of pull requests and the versions they got
included in.

[deeky666]

@zeroedin-bill I don't see we actually currently support/use this in platforms when generating SQL. Supporting this solely for SQL Server does not make much sense IMO. Besides that the benefit of supporting named primary keys seems rather low at this stage of development so I'd suggest marking this as possible feature for 3.0 and discarding this partial implementation for now. What do you think? If you agree, I'd suggest closing this PR for now and opening an issue instead (considering that the code base in 3.0 will heavily change anyways, making this patch obsolete) and mark it for 3.0.

[billschaller]

AFAIK named PKs can be supported on all the RDBMS we support. Would be good to have this in 3.0 because it would reduce churn on schema diffs against existing databases.

Scenario:

User has a database with a bunch of preexisting tables. They generate doctrine entities to reference the tables. They make some changes in their doctrine models and want to generate a SQL change script to modify the tables. (They could just do this by hand.) If any key columns are modified, the DBAL should drop indexes on those columns prior to altering them. If named PKs are not supported, the PK with a nice name would be dropped and then added with an autogenerated name.

Not really high priority, but since named PK support wouldn't really be hard to add, and all the platforms would support it, it would be nice to have support for it in DBAL.

[billschaller]

Closing, see #2294