r289932 causes pf reversion - breaks rules with broadcast destination

Commit r289932 causes pf rules with broadcast destinations (and some but not 
all rules after them in pf.conf) to be silently ignored. This is bad.

this broke access to my samba shares, and every "pass in ..." rule occurring
after the samba rule in my pf.conf.

for example, the host in question is a file server that allows SMB access on
my DMZ network. prior to r289932 the I could allow clients to browse shares
with pf rules such as:

pass in log on $dmz_if proto tcp from $ext_if:network to $dmz_if:0 \
     port { 137 139 445 }
pass in log on $dmz_if proto udp from $ext_if:network to $dmz_if:0 port 137
pass in log on $dmz_if proto udp from $ext_if:network to $dmz_if:broadcast \
     port { 137 138 }

after r289932 the 3rd of these was silently ignored -- pf parsed it w/o
complaint and listed it w/ "pfctl -s rules" but packets that should have
been allowed were instead matched by my default rule 0 ("block log all")
as were packets that should have matched later pass in rules.

it did not matter if the rule used an explicit address (... to 10.10.61.255)
or interface (... to re0:broadcast) or a macro (to $dmz_if:broadcast).

I do not understand the pf code well enough to see why this change caused
the breakage, but I suspect that it might expose some deeper problem and
should not simply be reverted.

tom