Proposed RosettaScripts syntax alterations to make using MultiplePoseMover easier

[roccomoretti]

@ajasja had requested some changes/additions to the MultiplePoseMover system to make using it more convenient. In particular, to reduce the requirement for specifying a full RosettaScript, and to allow MuliplePoseMover functionality (and thus control flow) to be more easily specified in the PROTOCOLS section.

This PR:

• Adds the ability to specify a pre-existing mover (defined elsewhere) in the MultipleOutputWrapper. (Also fixes an issue where the datamap of directly included non-full RosettaScripts wasn't set properly.)
• Allows MultiplePoseMover to take a pre-existing mover (defined elsewhere), rather than a sub-tag.
• Adds the ability to specify a PROTOCOLS subtag in MultiplePoseMover, which is taken to be a ParsedProtocol (i.e. sequential) mover specification, rather than a full RosettaScripts specification. (Uses same other-object definitions)
• Add the ability to specify a FOR_EACH_POSE tag (vs. an Add tag) in the PROTOCOLS section or the ParsedProtocol Mover, which is taken to be a MultiplePoseMover.

This should allow you to do something like the following as your main protocols block (no complete ROSETTA_SCRIPTS needed):

    <PROTOCOLS>
	<Add mover="multiple_output_wrapper" />
        <FOR_EACH_POSE>
            <PROTOCOLS>
		<Add mover="multiple_pose"/>
                <FOR_EACH_POSE>
		   <PROTOCOLS>
                       <Add mover="design"/>
                   </PROTOCOLS>
                </FOR_EACH_POSE>
            </PROTOCOLS>
        </FOR_EACH_POSE>    	
    </PROTOCOLS>

This is just a draft, and we may want to adjust the syntax and/or semantics of how things work. (Most notably, there's differences in object-sharing between different runs which comes along with re-using top-level movers/etc., rather than re-specifying a full RosettaScript which gets re-parsed for each pose.) We probably also want to see how it fares in practical use (e.g. @ajasja's driving use cases).

No current functionality should be erased by the syntax changes.

[ajasja]

Thanks @roccomoretti, this is amazing! I am out of office until aug 18, but will test/review as soon as possible.