Improve communication between MAP-Client and PMR

[tsalemink]

This PR addresses issues occurring with the communication between the MAP-Client and the Physiome Model Repository (PMR).

The usage in the MAP-Client of a couple pmr2.wfctrl classes has been updated to align with the current PMR2 API:

• The PMR2 CmdWorkspace class requires a Cmd object instance as an argument. The get_cmd_by_name method we are using in the MAP-Client returns a class type so the return value must be instantiated before passing it to the CmdWorkspace constructor.
• All PMR2 BaseDvcsCmd subclasses now output the Git command return-code in addition to the stdout and stderr streams. This can be used to more accurately filter error messages passed to the MAP-Client from the pmr2.wfctrl package. This is now being used in the MAP-Client to address an issue we have been having where some of the Git push commands we are executing to submit content to PMR return error messages even when the return_code shows that the push was successful.

Two methods have been added to the WorkflowStepMountPoint: gitInclude and createGitIgnore.

• The gitInclude method can be overridden by a plugin implementation to specify a list of files or file types that should be included under the step's workflow sub-directory in the version control of the workflow.
• The createGitIgnore method is called by the MAP-Client to create a .gitignore file for each of the workflow steps in the workflow directory. This will ignore all files in the step's workflow sub-directory except those specified by the plugin's gitInclude method. The WorkflowWidget._commitChanges method has been updated slightly so that step workflow sub-directories are included in the commit to PMR. Note that since the plugin specific .gitignore files exclude all file types by default, the step workflow directory will only be committed to PMR if the plugin implements the gitInclude method.

[tsalemink]

I thought I should include some additional information about the limitations of the workflow step .gitignore files.

I have chosen to use plugin specific .gitignore files to specify what should be added to workflow version control because this works well with the existing PMR Git communication but will also work if the workflow is being manually version controlled (e.g., cloned from a mapclient-workflows repository). Also, it only requires a minimal implementation to get this to work. Unfortunately, this makes it somewhat difficult to allow the user to override the .gitignore files for the workflow steps since the sub-directory .gitignore files will automatically override the one in the workflow root directory. Because of the default .gitignore hierarchy I am currently removing all plugin specific .gitignore files if there is a .gitignore in the workflow root directory to give the user this override ability. This works for both the internal PMR workflow version control and external workflow version control. It is possible to implement a more complex override method that takes the contents of all .gitignore files into consideration rather than just deleting the plugin specific files, but would require some significantly more complex pattern matching so I have skipped that for now.

Alternatively, we could replace the plugin specific .gitignore files with something custom - like a .gitinclude file. This would give us more control over the Git communication between the MAP-Client and PMR internally, but we would lose the ability to have external workflow version control make use of these files.