Adding test for broken "set every", see #1430

To test, use:
> scripted tests/set-every
This commit reverts part of 322f6de6551665cade7d56b532348ea5dc3d54db

The implementation of Relation should in theory make no difference
whether an element is unmapped, or whether it is mapped to an empty
set. One of the changes in 322f6de6551665cade7d56b532348ea5dc3d54db
introduced an optimization to the '+' operation on Relations that,
in theory, should have made no difference to the semantic.

The result of that optimization is that some mappings of the form
"elem -> Set()" are no longer inserted in the forwardMap of the
Relation.

Unfortunately, the change resulted in the breakage of #1430,
causing "set every" to behave incorrectly. There must be, somewhere
in the code, a test on the presence of a key rather than an access
via <relation>.get(), or some other access that bypasses the
supposed semantic equivalence described above. I spent several
hours trying to track down exactly the offending test, without
success.

By undoing the relevant change in 322f6de6551665cade, "set every"
works again. That however offers no guarantee that everything else
will keep working correctly; the underlying quirk in the code that
depends on this supposedly inessential detail is also still
lurking in the code, which is less than ideal.
Undone the revert on the optimization, and fixed setAll()

The optimization, and therefore the change in the behavior
of Relation, is now needed by the class Logic, and cannot
be reverted.

This patch (written by Josh) therefore changes the
implementation of setAll() so that _1s is no longer used.
Merge pull request #1591 from cunei/wip-set-every-1430

Fix for #1430