Injector: opt-out functions

[bennn]

In https://github.com/utahplt/FloatTrackerExamples/issues/5 , one of the random injections wound up in a function that (I claim) is protected against NaNs.

Even if my claim is wrong, it'd be helpful to ignore that function and let random NaNs appear in other places.

(For now there is a workaround: target specific functions one at a time. That might be better overall.)

---

The current injector supports only opt-in functions & libraries:

## Injector Fields

 - `active::Boolean` inject only if true

 - `ninject::Int` maximum number of NaNs to inject; gets decremented every time
   a NaN gets injected

 - `odds::Int` inject a NaN with 1:odds probability—higher value → rarer to
   inject

 - `functions::Array{FunctionRef}` if given, only inject NaNs when within these
   functions; default is to not discriminate on functions

 - `libraries::Array{String}` if given, only inject NaNs when within this library.

 - `record::String` if given, record injection invents in a way that can be
   replayed later with the `replay` argument.

 - `replay::String` if given, ignore all previous directives and use this file
   for injection replay.

`functions` and `libraries` work together as a union: i.e. the set of possible NaN
injection points is a union of the places matched by `functions` and `libraries`.

[ashton314]

Here's an idea: we go all the way to logical predicates on stack frames.

Location specifiers:

• in-module <module> True if specified module is topmost on the stack (excepting FloatTracker frames of course)
• dyn-in-module <module> True if the specified module is anywhere on the stack (dynamic extent of module)
• in-file <file> (Same)
• dyn-in-file <file> (Same)
• in-func <funcname + filename> (Same)
• dyn-in-func <funcname + filename> (Same)

Then we can combine them with and, or, and not. Top level might be an implicit and or or, depending on if we want the semantics to be inclusive/exclusive by default. (i.e. If we name and use the parameter as inject= or no_inject=.)

[bennn]

Sounds impressive, but also hard to implement. We'll need to normalize, check for vacuity, etc.

Let's leave this open until we have 3-5 examples of ways we might want to inject.

Then, use the examples to guide toward a low-work high-reward design.