Introduced ActivityType is now non-localized (i.e., English) value

[dennisguse]

GPXs <type> doesn't specify if it should contain localized or non-localized (i.e., English) content, but most applications use the non-localized approach.
OpenTracks was doing the former and actually didn't store a non-localized activity type at all, but rather just the information about the icon.

What has been done:

1. Introduced Track.activityType in addition to Track.activityTypeLocalized
2. Removed ActivityIcon as the icon identifier is superseeded by ActivityType
3. Implemented database migration to determine TracksColumn.ActivityType (first using activityTypeLocalized and then icon (sadly it cannot be perfect)
4. KML now export and import activityType and activityTypeLocalized
5. KML does not export/import icon anymore
6. GPX now export <type> as activityType while the import should be able to handle activityType OR activityTypeLocalized (BREAKING CHANGE)

As usual there are likely some edgy edge cases.

PS/ KML parsing using SAX is just horrible.

[dennisguse]

@pstorch I am in need for another sanity check.
This PR does a data migration and I hope, I didn't introduce some unexpected features....
I am interfering the newly introduced ActivityType from the stored icon values (sadly a 1 to many mapping) or from the stored (localized or manually entered) activity type.

[pstorch]

I did a quick test. Upgrade existing tracks worked. Export and Import with the same language worked. Export and Import from different languages resulted in UNKNOWN track types (I guess as expected).

[dennisguse]

@pstorch Sounds good.
And yes, the localized lookup only works if the imported file has the same language as OpenTracks.
Did you see any issues with the db migration?

[pstorch]

Did you see any issues with the db migration?

No obvious issues.

[dennisguse]

@pstorch release and merge it is.
And making a backup from my nightly :D