Allow configuring sproc mapping to use parameter names for invocation

[AndriySvyryd]

This can be used avoid parameter ordering issues and avoid sending default values when there are many optional parameters

Split off from #245

[roji]

If we don't do this for 7.0, we may want to remove the HasName API on the parameter builders.

[AndriySvyryd]

If we don't do this for 7.0, we may want to remove the HasName API on the parameter builders.

Since the values are effectively unused we can change them in the future without it being a breaking change.

[roji]

Sure, but wouldn't users find it confusing to have this unused configuration, any reason not to remove it until we make use of it?

No strong feelings though if you want to keep it.

[AndriySvyryd]

At this stage it's more work to remove it

[dekenless]

To clarify, in EF 7 the calling of stored procedures for CUD operations will only be positional? I think it is important to be able to define the mapping between column name and parameter name. This ability is helpful in ensuring breaking changes are not introduced into ones code base and to ensure there is not an inadvertent parameter to column mismatch. Moreover, those organizations with large EDMX models want the ability to automate the conversion to EF Core (i.e. the EDMX does have the mapping and a T4 transformation allows for the definition of the entity to stored procedure mapping)

[roji]

@dekenless that's right - EF7 will only support positional parameters in CUD sproc mapping; one reason for this is that while all databases support positional parameters, not all support named (see here for more info). This issue tracks adding named parameters in the future.