[1125439] Duplicate baselines metric entries

Although the root cause is still unknown the relevant code paths did not
protect against generating multiple baselines for a single schedule, even
though that should be invalid.  Here are some changes that are more in line
with the 1-1 relationship that should exist between schedule and
baseline (optional for schedule, required for baseline)
- Make the db index on baseline's scheduleId unique. There should only be
  one baseline for a schedule. This will prevent the problem in the BZ, possibly
  at the expense of failure when trying to store a duplicate, but that would
  perhaps help us pinpoint a problematic code-path.
- Use Sets (or a Map) as opposed to Lists in several places in the local API.
- Simplify and I think make more efficient the query for selecting schedules
  without a current baseline. Make it return distinct ids (this is a hedge,
  I don't think it would return duplicates, but this ensures that constraint).
  Replace a left join with a NOT EXISTS sub select.
- Chunk the storage of baselines to prevent large Txs, don't pass entities
  across Tx boundary, fetch all Schedules in one query, and (maybe) simplify the
  entity manager interaction.
- Simplify some of the TransactionAttribute decls
- Mark MeasurementSchedule.baseline as an optional 1-1 relationship, just to make
  it explicit on the entity.
- Fix some local SLSB jdoc