Turned out that I could not guarantee that emulab-networkd@.service
would write the .network files in /run/systemd/network in time for
systemd-networkd to notice them; so I tweaked the strategy to a slightly
more complex path: udev rules run a simple shell script that writes the
per-device .network files that specify dhcp on all interfaces, in
addition to telling systemd to want emulab-networkd@<dev>.service units.
These units wait for the control net to come up on one of the devices;
then the winner removes the extraneous .network files and downs the
unused interfaces and restarts systemd-networkd so it only "manages" our
control net.

I also improved it so that if the user writes static systemd-networkd
configuration into /etc/systemd/network/<foo>.network, our udev rules
still write /run/systemd/network/<foo>.network if foo is a physical
device -- but the waiter unit and cleanup scripts do *not* down <foo>;
they just ignore it, because they notice that systemd-networkd did *not*
pick our /run/systemd/network/<foo>.network to manage <foo>.  So we
should be good for integration and not squashing static user configs.

Finally, I "completed" it in the sense that the winning
emulab-networkd@.service unit also writes out all the /var/emulab/boot
metadata, sets the hostname -- does what the dhclient exit hooks used to
do.

The only thing it does not yet handle is elabinelab dhcp "selection".  I
need a quick semantics tutorial for that.