Explicitly permit SCND bits that can update match MWS primaries

[apcooper]

Explicitly permit secondary bits that can change the state of matched MWS primary targets.

Previous behaviour was to allow such updates to be driven by any target with SCND_ANY. Now checks for mwsupdate=True flag in target bit definition.

[coveralls]

Coverage decreased (-0.8%) to 58.889% when pulling 0af02f5 on scnd_updatemws into 5461c52 on master.

[sbailey]

Thanks @apcooper . Please update the variable names and comments to avoid "whitelist" (and implied "blacklist") terminology. allow / permit / include / override are possible alternatives.

[geordie666]

@apcooper: Just so you know, I took the updates you made in the bit-mask yaml file in this branch and ported them to the Main Survey bit-mask yaml file in my working branch. So, you won't need to also do that in this PR. In other words, I have retained your mwsupdate=True/False choices for the Main Survey in my working branch.

[apcooper]

@geordie666 OK thanks for doing that. You say I won't need to do that -- I've done it already, so do I need to undo anything?

@sbailey noted, will fix.

[geordie666]

Yeah, if you could remove any changes in py/desitarget/data/targetmask.yaml that'd be great. I already have those changes in my working branch (and I have a lot more additional changes in my branch). It might be easier for me to merge the branches if you just undo anything in py/desitarget/data/targetmask.yaml. Thanks!

[apcooper]

@geordie666 I think this is working -- I've tested it a bit and have corresponding unit tests, but some of them assume things are set up as expected in the targetmask.yaml, which is not the case now per your request. I can add these later once everything is merged, if needed.

The result of this PR is that the previous behavior is recovered if and only if updatemws=True.

@sbailey I've changed the terminology.

[apcooper]

The last commit seems harmless and allows the tests to pass in without corresponding changes to targetmask.yaml, but I'm not sure if it fits with the style for the other flavor-like flags.

ps. "options" in the commit message should be "optional".

[geordie666]

Thanks @apcooper. This looks like carefully written code, as always. I checked a few basic use cases and it seems to work fine.

I have a couple of comments regarding backwards compatibility and the tangled web of PRs we've been creating. But, feel free to merge once those comments are addressed.

[geordie666]

Looks good! Feel free to merge once tests pass.