fix #59 chaining of setup.sh files generated by rosinstall/rosws
The previous behavior only worked when a rosws workspace overlayed
e.g. /opt/ros/fuerte, but generated an invalid ROS_PACKAGE_PATH when
chaining another rosws workspace using the setup-file element

The cause was that the env variables used in setup.sh got changed
in the recursion.

The solution here is to use the global variables in the recursion,
as an accumulator for the ROS_PACKAGE_PATH, and a producer-consumer
stack for the list of setup files to source.
This implies preventing variables to be accidentally reset or unset
in nested calls to setup.sh files,

A new test tests chaining twice and chaining more than one setup-file
element, to prevent regressions.

non-rosws-generated setup.sh files may delete ROS_PACKAGE_PATH on their own
So when entering recursion, _ROS_PACKAGE_PATH_ROSINSTALL collects the items to add
when the last recursion is done, all the elements in there get prepended to the ROS-PACKAGE_PATH

This means the resulting ROS_PACKAGE_PATH may be surprising, as it may
contain elements which, if the corresponding setup.sh files had acted on
the ROS_PACKAGE_PATH in the order they are sourced, would have disappeared.

The only really supported usage of setup-file remains overlaying
a single non-rosws workspace with a rosws workspace. Users may try
overlaying rosws workspace with rosws workspaces, but this commit does
not encourage this, due to the quirky behavior.
Merge pull request #60 from tkruse/fix_chaining

fix #59 chaining of setup.sh files generated by rosinstall/rosws