Type-unstable hot loops

[luke-kiernan]

Address type-unstable hot loops. Things worth trying, or order of invasiveness:

1. Introduce a function barrier. Replace

for d in devices # typeof(d) varies: loop body is type unstable.
    # code here won't specialize.
end

with

for d in devices
    _inner!(container, d, ...)
end

function _inner!(contrainer, d::D, ...) where {D}
    # compiled per concrete D: code here will specialize
    # (still a runtime dispatch, though)
end

If the loop body is sufficiently complex, and devices contains a couple different concrete types, the 2nd should win out. This may increase compile-time, though, so it's worth measuring.

2. Add a replacement for FlattenedIterator that unrolls across the different types. See IS #505. Requires interface work in IS (prototyped in that PR) plus rewriting the loops to use map and similar.

[luke-kiernan]

A first step would be to simply figure out which loops are the major offenders. Also, some of this applies to POM too.

[jd-lara]

The device models now store vectors of the components. It sould aleviate these kinds of issues. We should start moving the code to iterate over those instead of over the flatter iterator wrappers