Override composer task parameters from your environment (stage|production) config file

[t0k4rt]

Hi, I ran into the same problems as described here #39 #22
In the composer task, shared_path and release_path are not evaluated accordingly to the environment.
The bug is simple to reproduce:
When you override deploy_to path in your stage|production ruby file with a path different from your deploy.rb file, the composer task will run with the deploy.rb deploy_topath so that both release and shared path will be wrong when launching composer tasks.
The workaround I found is to load default paths using lambdas:

namespace :load do
  task :defaults do
    ...
    # use ruby global variables in a lambda
    set :composer_working_dir, -> { "#{release_path}" }
    set :composer_path, -> { "#{shared_path}" }
    set :composer_use_global, false
  end
end

I added the variable composer_path so that I can override the SSHKit command_map with a lambda (since SSHkit.config.command_map = ->{ fetch(:myvar) } doesn't seem to work).
Also, instead of overriding the command in the deploy.rb, I override the variable directly in the rake tasks so that the variable is set accordingly to the environment we are deploying in.

With these changes, you can do whatever you want:

• override the deploy_to path
• override the composer_path
• override the composer_working_dir
  From your stage or deploy.rb files

I also added other stuffs:

• I added a check which checks whether composer is installed globally or not
• In case composer is not installed, I trigger composer:install_executable task (with a ask)
• This check is triggered whenever a composer task is triggered
  (before 'composer:run', 'composer:check')
• I added a flag which indicate that we prefer to use a globally installed composer instead of a locally installed version of composer

What do you thing about this ?

[t0k4rt]

Any feedback ?

[swalkinshaw]

This PR caught me while I was away on vacation so it got lost in the shuffle. Despite this being a limitation of Capistrano, I'd be open to potentially including a solution for it in this extension.

But I'd prefer if the code changes could be limited to only addressing that problem for one. There seems to be other changes going on in this PR. Can it be reduced to the minimum required to fix the original issue?