Fix double future resolve on error in FS

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

Fix double future resolve on error in FS
Fix setting of profile-dir

Add profileDir to knownOptions to prevent breaking of process when --profile-dir is passed on command line. The reason for breaking was yargs behavior, that adds values with dash as two keys - one with dash (profile-dir) and another one with removed dash and fist letter after it is replaced with its upper value.
Add setProfileDir function to options. It is used to set the profileDir based on client's default profile dir. The function adds the value to yargs.argv and to the exported options, so any code that requires options or yargs.argv will be able to use profile-dir.
Merge pull request #75 from telerik/vladimirov/fix-profile-dir

Fix setting of profile-dir
Parse yargs numbers to strings

Add conversion to strings of Yargs arguments which are numbers. All current commands expect string values as arguments, so we do not need numbers as they are causing exceptions in some cases. For example if you use appbuilder simulate --path 9, where 9 is valid directory, you will receive an exception.
Merge pull request #72 from telerik/vladimirov/validate-number-parameters

Add validation for number params
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.
PR comments - refactoring

Change validate method of ICommandParameter to returns IFuture<boolean> as some of the implementations of the method are using IFuture calls, so we have to be consistent. This leads to change in the return type of validateMandatoryParams, validateCommandArguments definitions to return IFuture<boolean> as well. Add executeCommandAction method to remove duplicate code.  Multiple smaller fixes (spelling errors, indentation issues, etc.).
PR comments - fix errors

Improve some messages when error is found.