Have the build system insert the STABLE constant rather than humans.

Humans are fallible, and our previous tests to make sure that stable
branches had the stable build symbol defined were flawed.

This change has the `bin/build` code insert the `STABLE` constant
automatically if we're on the appropriate branch.

This also removes the test that wasn't ever realising that our
previously defined stable symbols were commented out.

Happily tested by me.
bin/build: Options should be empty when not on stable
Merge branch 'release-v1.2' into moar_stable

* release-v1.2:
  Allows removal of multiple mods
  CmdLine: Tweaked message displayed on download failure.
  Re-catches DownloadErrorsKraken
  Tests: Discussed RelationshipResolver behaviour with installed mods.
  Fixed issues with pull request. Re-added if null check - removed by mistake. Added test to check this code. Removed Service in Tests.csproj
  Fixed bug and added more tests. Bus was in "sub_options = options". I assume the RROptions was a struct at some point?
  Adding basic tests to RealationshipResolver.
  Nunit requires public accessibility for testcases.
  Started work on a random module generator to aid in testing. Added a online category to some tests which require online access. Saved a copy of CKAN-meta-testkan.zip so that the sanity checker tests are offline. Fixed KSP.Training test to work on windows as well as linux. Moved tests in CKAN folder to match files in code.
  Have our build system actually include the icon.
  Transparent icons, larger range of sizes.
  Add a CKAN icon.

Conflicts:
	CKAN/CmdLine/CmdLine.csproj
	CKAN/GUI/CKAN-GUI.csproj
	bin/build
	bin/build.lean
The GUI and upgrade functionality is now considered stable. :)

Compilation change for the upcoming v1.2 release.
Merge pull request #546 from pjf/moar_stable

Have the build system insert the STABLE constant rather than humans.
Merge pull request #550 from pjf/stablise_gui_and_upgrade

The GUI and upgrade functionality is now considered stable. :)
Tests: Allow for -PRE in stable release numbers.

This means we can release `v1.2.0-PRE1` without our test cases going
silly. This release will read `v1.2` spec files (since its version
number is greater than the spec_version), but we're not necessarily
calling it a release candidate.

Internally `ckan.dll` and friends don't care about the version number at
all, except to compare it as a `Version` object against the
`spec_version` in our metadata. We could have `cheese sandwich` as a
version and the core would accept that as being okay. ;)
Merge pull request #553 from pjf/version_tests

Tests: Allow for -PRE in stable release numbers.
Adding the icon to the main form.
Starting ckan.exe with no arguments always start the GUI.

Previously this wouldn't do so if we had a "stable" build.

Hand tested by Australians. :P
Merge pull request #557 from pjf/stable_gui

Starting ckan.exe with no arguments always start the GUI.
Merge pull request #555 from RichardLake/release-v1.2

Adding the icon to the main form.
Merge branch 'release-v1.2'

* release-v1.2:
  Starting ckan.exe with no arguments always start the GUI.
  Adding the icon to the main form.
  Tests: Allow for -PRE in stable release numbers.
  The GUI and upgrade functionality is now considered stable. :)
  bin/build: Options should be empty when not on stable
  Have the build system insert the STABLE constant rather than humans.