Introduce field aliases

Views already uses them, and our Views integration does, too: field aliases. And since our current system of field IDs, with colons separating the individual parts, leads to problems in some subsystems (Views, some Solr functionality, …) it might be worthwhile to think about introducing a similar system in the Search API.
The field identifiers normally used would then be valid PHP identifiers (so no colons, dashes or the like), and we'd store the actual identifier (or "data selector" = the path to take through the different objects to reach the field) separately.

Since the clean identifier would then also be what would be used in URLs or other elements end users would see, we could also let admins freely set field aliases to provide nicer URLs and the like (?f[0]=qualification:10 instead of ?f[0]=field_collection3%3Afield_qualification:10) and to hide internals.