Determine how & detect Dev vs. Production

[marcpalmer]

• [ ] Decide how we will discover this at compile/run time
• [ ] Implement selective output of advisories etc. based on this
• [ ] Implement selective FIFO queue sizes for stacks and timeline based on this

[marcpalmer]

Note that we probably want to allow determining whether dev + prod loggers are available at runtime, not just compile time.

e.g. by default we'd include both targets but have some runtime toggle to determine which is created, but also have an #if !DEBUG && FLINT_COMPILE_TIME_LOG_TARGETS check to allow their creation to be compiled out.

[marcpalmer]

Having thought about this more, my current thinking is:

1. development/production logging is a runtime thing. Let developers use their own flags to set up Flint as necessary at runtime. As loggers are nil if not configured, this short circuits everything (although it leaves the code for logging at call sites - but that is always the case with non-macro logging)
2. there remain some safety & debug features and sanity checks that the developer may not want to include in release builds. For these we should require a FLINT_SAFETY_OFF compiler flag or similar. Users would need to explicitly build with the Swift flag defined to create a binary with these parts removed. In practice these are likely to be few and far between, but if there are performance gains to be had this would be good. We can make a flintSafetyXXX(_ block: ()->()) function that is a NOP if the flag is not defined.

[marcpalmer]

Punting until we are seeing the real world issues around this.