Does not support composite projects with relative paths to files about testengine-cli

[gpaciga]

I notice there is an inconsistency in how resourceRoot is handled between TestEngine and ReadyAPI for the above patch I proposed. Since I copied that handling from the non-composite project code, the issue presumably exists there as well.

Given a project with its root settings file at /path/to/readyapi/project/settings.xml, ReadyAPI defaults resourceRoot to /path/to/readyapi but path.dirname(pathname) in the TestEngine CLI just resolves to the current working directory, wherever that is (since pathname is just ".", not an absolute path). Assuming you run testengine-cli in the same folder as your settings.xml file, it would effectively be /path/to/readyapi/project/. This means that e.g. file paths in a Data Source step will point to two different locations depending on whether or not you run the project with TestEngine CLI or with ReadyAPI.

I'm changing the fork we use to let resourceRoot = path.dirname(path.resolve(pathname));.

[gpaciga]

I've abandoned trying to get a fork of testengine-cli to work, and am instead using an external script to create a zip file and pass that to testengine-cli. Took some trial and error to figure out the right structure for the zip since it is undocumented, but for anybody else facing this: Data Source files need to be co-located with the root settings.xml file, regardless of the path used for them in <file> property.