Update WXS file to enable MSI rollback

This change updated the 'Upgrade' logic in the CRD host WXS file
so that it no longer blocks downgrades.  I've run through several
upgrade and downgrade scenarios and it looks like everything gets
cleaned up and re-registered correctly with this change.

I looked into a few options to constrain the version window where
downgrades are allowed.  I think the most promising would be to
add a wxs param which takes a 'max_downgrade' var based on the
'chrome_version_full' + max version skew and use that for
blocking downgrades.  I'm not convinced this is necessary though
since we don't have any version checking for our MacOS package
and we haven't had any issues related to downgrading when using
Keystone.

Bug: 1148967
Change-Id: I4b36541ff901eb10f4c26c7652654f43f77762c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2538202
Commit-Queue: Joe Downing <joedow@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#827456}

remoting/host/installer/win/chromoting.wxs

@@ -111,7 +111,7 @@
     <Upgrade Id="$(var.UpgradeCode)">
       <UpgradeVersion IncludeMinimum="no"
                       Minimum="$(var.Version)"
-                      OnlyDetect="yes"
+                      OnlyDetect="no"
                       Property="NEWERVERSIONDETECTED" />
       <UpgradeVersion IncludeMaximum="yes"
                       IncludeMinimum="yes"
@@ -120,10 +120,6 @@
                       Property="OLDERVERSIONBEINGUPGRADED" />
     </Upgrade>
 
-    <Condition Message="A later version of [ProductName] is already installed. Setup will now exit.">
-      NOT NEWERVERSIONDETECTED
-    </Condition>
-
     <Media Id="1" Cabinet="chromoting.cab" EmbedCab="yes"/>
 
     <Directory Id="TARGETDIR" Name="SourceDir">