Update std::shared_ptr argument passing to be closer to idiomatic C++.

[jpieper-tri]

The CppCoreGuidelines recommend that std::shared_ptr only be passed as
an argument when the callee explicitly needs to manage the lifetime of
the argument, and that 'const std::shared_ptr&' should only be used
if there is a chance that lifetime will not be shared.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rr-smartptrparam

Many instances in drake were passing 'const std::shared_ptr&'
around, often when no lifetime management was necessary, and otherwise
when lifetime sharing was unconditional. This can be less efficient,
unnecessarily restrictive, and hides the intent of the API.

This patch converts those instances either to:

• [const] T& if no lifetime sharing is required
• std::shared_ptr if lifetime sharing is always required

[sherm1]

Some build failures, e.g.:

/tmp/drake-1797-9134/drake/systems/plants/constructModelmex.cpp:254:45: error: non-const lvalue reference to type 'RigidBody' cannot bind to a value of unrelated type 'shared_ptr<RigidBody>'
        model->addCollisionElement(element, b, group_name);
                                            ^
/tmp/drake-1797-9134/drake/../drake/systems/plants/RigidBodyTree.h:526:18: note: passing argument to parameter 'body' here
      RigidBody& body, const std::string& group_name);
                 ^

[jpieper-tri]

sherm1: Thanks, hopefully fixed, although I'll have to rely on CI as I don't have matlab locally to test.

[sherm1]

This and some of the nearby methods would be clearer with a utility method something like

return (parent->isSameRigidBody(other) && ...);

[sherm1]

Looks good to me, pending builds.

[jpieper-tri]

Well, the windows jenkins build failed, and while the build output is full of warnings, I think the actual failure was just #1787 ?

[sherm1]

the windows jenkins build failed ... I think the actual failure was just #1787?

Yeah, the patch command is missing.

[jpieper-tri]

Updated to fix merge conflicts.

[jpieper-tri]

Does anyone know why jenkins failed here? It looks like it was trying to pull the incorrect git hash?

[jhoare]

retest this please

[jpieper-tri]

Great, I believe the spurious Windows jenkins failures are now resolved.

[RussTedrake]

@jamiesnape -- why did this pass on jenkins (but not appveyor)? it should not have passed without #1843 being merged.

[jamiesnape]

@billhoffman added an environment variable specifying the generator for now.

[jamiesnape]

(in the Jenkins build script, that is)

[RussTedrake]

that doesn't explain why the pendulum urdf test passed.