Ensure that dynamic polymorphism with templated types play well with symbol visibility on Mac

[EricCousineau-TRI]

Summarizing from this comment and the follow-up from #8435:

jamiesnape commented:

AbstractValue: a request to extract a value of type 'drake::systems::BasicVector<double>'
failed because the actual type was 'drake::systems::BasicVector<double>'.

jwnimmer-tri commented:

That's consistent with having more than one typeinfo in play. The typeinfo requirement for process-wide uniqueness vs mach linker on macOS has been challenging in the past for us.

EricCousineau-TRI commented:

Seems that I just got bit by the above symbol visibility mismatch with Mac in the following PR:
RobotLocomotion/drake-external-examples#98
Specifically failing in this Mac build:
https://travis-ci.org/RobotLocomotion/drake-shambhala/builds/363828263#L2747-L2756

Traceback (most recent call last):
  File ".../example_module_test.py", line 68, in <module>
    main()
  File ".../example_module_test.py", line 60, in main
    simulator.StepTo(1)
RuntimeError: LeafOutputPort::Calc(): Expected a vector output type for output port 0 of shambhala::(anonymous)::SimpleAdder<double> System ::_::shambhala/(anonymous)/SimpleAdder@00007fc640e0bf90 but got a drake::systems::Value<drake::systems::BasicVector<double>> instead.

Seems that this is a problem that would not be fixed by resolve this PR, nor the above solutions (compacting pydrake into a single statically-linked library).

The short-term solution to this would be to somehow teach the Mac linker to produce the same typeinfo for these symbols downstream.

TBH, it's a little mystifying to me that it can link functions of signatures with the same type, but fails to produce the same RTTI for the given symbol.

\cc @jamiesnape @jwnimmer-tri

EDIT: I understand a bit more on the symbol visibility shenanigans, why the symbols link well at compile-time, but why there's a mismatch at runtime (since clang and what not checks RTTI based on pointer comparison and not string comparison) (reference).

Relates #7856

Will see if the PR itself can be fixed by overriding the -fvisibility=hidden flag from pybind11Tools.cmake.

[jwnimmer-tri]

Closing as not planned.