Fix double future resolve in file system

Fixes http://teampulse.telerik.com/view#item/277062
Merge pull request #485 from Icenium/totev/fix-double-future-resolve

Fix double future resolve in file system
Fix setting of profile-dir

Set profile-dir option with commonOptions setProfileDir function. Add tests for setProfileDir function to make sure correct value is used.
Merge pull request #486 from Icenium/vladimirov/fix-profile-dir

Fix setting of profile-dir
Add tests for -- arguments

Add tests for null value, undefined value and number.
Merge pull request #482 from Icenium/vladimirov/validate-number-parameters

Add tests for -- arguments
Fix spelling

See http://teampulse.telerik.com/view#item/276957
Merge pull request #487 from Icenium/totev/fix-err-msg

Fix spelling
Bump version to 2.6.0
Merge pull request #488 from Icenium/totev/v2.6.0

Bump version to 2.6.0
Add validation for command parameters

Add validation for the parameters that each command accepts. Add logic to check if command has mandatory parameters and all of them are provided - if any of them is missing, command is not executed. Add logic to validate all arguments passed to command - if the command does not accept arguments, but there are some passed to it, it is not executed. Add ICommandParameter interface to describe command parameter. Add allowedParameters property to ICommand interface. Add canExecute method to ICommand interface. It is not mandatory to implement it and it is used when the command will validate the parameters on its own. The common validation is implemented in CommandsService.

ICommandParameter describes one parameter that the command accepts. It can be mandatory for the command or not. That's why I've added mandatory boolean parameter to the interface. Each parameter have its own logic for valid values, that's why ICommandParameter has validate method. It is called from the CommandsService when the arguments are validated. CommandsService itself tries to validate all command arguments. One special case is when the command is hierarchical. In this situation the root command is validated first, but it doesn't have own definition, so it doesn't have allowed parameters. That's why CommandsService checks if the command is valid hierarchical command.  If command has canExecute method implemented, CommandsService will use it to validate the arguments. If not, it will try to validate all passed command line arguments with the allowed parameters of the command, by checking their count, calling validate method, etc.

Each command has different number of allowed parameters. In most of the cases the command parameter is string and the only requirement for it is to be non-empty. That's why new StringCommandParameter class is added. It is used to define such parameters. In case the parameter has more complicated logic, new class, that implements ICommandParameter is added for it.

Remove all helpers.registerCommand calls. Remove registerCommand methods. Add tests for CommandsService and some stubs.
PR comments - refactoring

Move some commands to command folder. Rename cloudProjects file to cloud-projects. Rename remote-projects to remote-projects-service and moving it to services folder. Fix command parameters validate method to return IFuture<boolean>. Multiple smaller fixes (spelling errors, indentation issues, etc.).
PR comments - fix errors

Fix samples commands by using correct filename in bootstrap. LiveSync uses constructor injection for StringCommandParameter. CloneSampleCommand has one mandatory parameter.