CPack/WiX: Set "InstallScope" to "perMachine" by default or make configurable

(Discussion following !5016 (closed))

Problem

The CPack WIX Generator currently does not set the InstallScope property on the Package Element.

As a result it behaves as if perUser was set, i.e. only creates desktop shortcuts / start menu entries for the current user and also the un-installation entry is created for the current user only (which is a problem as it makes it impossible for other users to remove the software and throws off most deployment software).

A more suitable default (especially considering the default install location is relative to the "Program Files" folder which is only accessible with elevated privileges and shared by all users of a machine) would be to set InstallScope to perMachine which asks for elevation automatically and effectively sets the ALLUSERS property to 1.

Solutions

1. The pragmative approach proposed in !5016 (closed) would be to simply add the property to the default WiX template.
   Currently there are concerns that this would be a backwards-incompatible change, however I'd rule the current behavior a bug and most likely not what most packagers want, so I assume that - even if it changes behavior - the change would benefit most projects making use of CPack. Some of them might not even be aware of the issue. (For example the Inkscape project started to use CPack for it's 1.0 release and immediately hit this bug unknowingly, which resulted in multiple independent user reports - [1], [2], [3] - and overshadowed the otherwise smooth transition from custom packaging).
2. An alternative that keeps backwards-compatibility would be to make this property configurable, so it can continue to default to perUser , but can be set to perMachine as a choice.
   Downside of this solution would be that it would keep the less than ideal default.
3. A third suggestion is to investigate policies for CPack.
   Considering that this requires significant effort for a "trivial" change I personally am skeptical about this solution. (Even more so as personally - as a CMake user - I feel the policy mechanism is inconvenient to use, therefore rarely ever helps to get new behavior adopted faster, and on top of that often adds more confusion than it avoids).