Add support to SDK-style projects (.net core).

[ImrePyhvel]

.net Core projects operate slightly differently regarding versioning, i.e. setting the base version as project properties and not the AssemblyVersionAttribute in code. The actual attributes are written to compiled code by net MSBuild targets, and my become in conflict with the attributes generated by this tool.

Also, the Properties folder is no longer existing in templates, making it a bad choice to store the configuration and output file.

SCope of the task is to make the tool work for .net standard/core projects.

[ImrePyhvel]

Made the following adjustments:

• Props configuration file is no longer added to project by default.
  • The go-to way is to add the configuration options directly to csproj file.
• Changed the defaults to more reasonable values so configuration is usually not needed at all
  • FileVersionAttribute: Skip -> HumanReadable2SlotTimestamp
  • AssemblyConfigurationAttribute: Skip -> HumanReadableBuildInfo
• No longer assuming the existence of Properties folder for AssemblyInfo.cs, output file or configuration
  • if Properties folder exists then it is still used.
  • if it does not then use project root.
• AssemblyInfo.cs and AssemblyVersionAttribute no longer required
  • Task is now passed in explicit base version from .net core default version property (assemblyVersion). If this is given, then input attribute file is ignored. If it is not given then the old behavior is still there to support .net fw.
• automatic suppression of generating duplicate attributes for SDK-projects
  • working with Microsoft.NET.GenerateAssemblyInfo.targets to suppress only those attributes that the tool is configured to create.
  • NB! this is slightly dirty , as MSBuild still has the default .net core version properties in memory which will not end up in version attributes but may impact other logic assuming they are the real thing. Fix would have forked the logic more from .net FW behavior. Keeping it simple for now.

This should enable the following scenarios to "just work", without any manual tricks:

• .Net FW + packages.config
• .Net FW + packagerReference
• .Net Core/Standard out of the box.
• .Net Core with AssemblyVersionAttribute (via GenerateAssemblyInfo=false)

These changes also solve #11 as a side-product.

[ImrePyhvel]

As the new .net FW project template already contains FileVersionAttribute and AssemblyConfigurationAttribute then the change of default would cause all those projects to get errors:

• CS0579 Duplicate 'AssemblyFileVersion' attribute
• CS0579 Duplicate 'AssemblyConfiguration' attribute

Added checks that every time AssemblyInfo.cs is scanned for base version:

1. IF file contains conflicting FileVersionAttribute AND file version generator is not Skip then log a descriptive error message.
2. same for AssemblyConfiguration attribute

Example:

Error		'Properties\AssemblyInfo.cs' contains FileVersionAttribute. This is in conflict with auto-generated attribute. Please remove this conflicting attribute or omit FileVersionAttribute from automatic generation. See https://github.com/nortal/AssemblyVersioning/wiki/Generator-options for more info.
Error		'Properties\AssemblyInfo.cs' contains AssemblyConfigurationAttribute. This is in conflict with auto-generated attribute. Please remove this conflicting attribute or omit AssemblyConfigurationAttribute from automatic generation. See https://github.com/nortal/AssemblyVersioning/wiki/Generator-options for more info.