A continuation of #15

There may be incompatible changes in configuration schema between versions. To support that:

1. A configuration file should has a property Version. It is better to have it as a property instead of filename, because configuration files may be per projects.
2. The version number should be separate from assembly version because there may be no configuration schema changes between different SCS versions.
3. When SCS is updated it should attempt to (an investigation is needed what is possible):
   • update the config in AppData in VS extension case. Since the location is shared between different installations (vs2015, vs2017 and nugets) the upgrade should create a new file in the folder (version number in the file name).
   • update the config in project when NuGet package is updated or during analysis in VS extension case (Investigate if it is even possible to have two versions of SCS running from NuGet and from VS extension at the same time. If it is, then maybe VS extension should convert the config in memory on the fly only).
4. If upgrade has failed or the version number is newer than supported SCS should show a fake analysis warning (SCS_Error1?) when the analysis is kicked off.
   • SCS_Warning for a suggestion to upgrade when doing memory only upgrade?
   • Since a user may change the number manually or the file maybe corrupted SCS_Error is needed if an exception happened during config loading.