Build InstrumentPlans in Psc::ScheduledActivity.  #2426.

As part of this commit, the construction of implied entities was moved
to Psc::ScheduledActivity.

Why?

It's much easier to build plans when you have access to the activity and
everything it implies.

In order to build an InstrumentPlan, you need the instrument and surveys
implied by the activity; and if you're going to work on the instrument,
the easiest way to check if two instruments are the same is to check
their structure, which includes checking the event and person referenced
by that instrument.

One *could* do all of this by just checking labels, but
Psc::ScheduledActivity is IMO much nicer to work with.

Next up: modify Field::ScheduledActivityReport and
Psc::ScheduledActivityReport::EntityResolution to work with
InstrumentPlans.
Add implied surveys from instrument plans.  #2426.
When building plans, ignore activities that don't imply surveys.  #2426.
Don't store model resolution results in implications.  #2426.

There's no need to ensure two implication objects point to the same
object in memory.  This lets us eliminate
ScheduledActivityReport::Collection; additionally, we longer abuse the
equality notions of Struct.

Also, it's less code:

    6 files changed, 147 insertions(+), 218 deletions(-)

This became important when #derive_implied_entities was moved from
Psc::ScheduledActivityReport to Psc::ScheduledActivity, with the
implication (ha) that implication objects could now be instantiated
multiple times.  Keeping around the hidden requirement for object
equality was just too much of a pain to deal with.
Stop namespace pollution.
Store implied surveys in InstrumentPlans.  #2426.

This better fits what a Psc::InstrumentPlan is supposed to provide.  It
also makes it possible to test participant type and order without having
to instantiate Psc::ScheduledActivity instances.

To facilitate this change, a few changes to Psc::SA::Implications
objects were made:

1. participant_type and order attributes were moved from Instrument to
   Survey.
2. SurveyReference, a struct with (currently) one member, was
   introduced.

(1) was done because participant_type and label are really attributes of
the _survey_, not the operational data for the instrument.  (2) is a
consequence of (1): the additional attributes on Survey means that it is
no longer possible to construct a Survey from a single references label,
so we instead store the referenced code and use that for lookup.
Link instruments -> plans in fieldwork.  #2426.

A note on the Fingerprint module, which implements content addressing
for Instruments (and most other implied entities as a result):

What I'd *really* like is to use activity names for instrument plan IDs, so
that an instrument named "Birth Interview" references an instrument plan
with ID "Birth Interview".

Unfortunately, I don't think that's possible.  AFAICT, there is nothing
preventing two activities that have identical names but different
instrument references.  If we were to use the instrument's activity
name, we would be using an unfounded assumption that could lead to some
odd errors down the line: a plan for one instrument showing up for
another instrument, for example.

Should that assumption be proven correct later on, I'd be happy to get
rid of Fingerprint.  Until then, though, this is the safer option.
Use latest ncs_navigator_schema.  #2426.
Update examples for new fieldwork schema.  #2426.