Add a design topic page on lazy vs. eager implementations

[rgommers]

Follow-up to gh-652, which added notes to the specifications for __bool__ & co on this topic.

[rgommers]

@seberg had one comment that is addressed in the second comment: point out that there is no built-in control flow beyond where (e.g., no cond) to avoid the __bool__.

[betatim]

Looks good to me

[rgommers]

Three approvals and comments are addressed, so I'll go ahead and merge this. Thanks all!

[betatim]

On a more philosophical note: what should an array consuming library do to deal with these two variants of behaviour? There are two options that come to mind straight away: (1) state in your docs that of all Array API compliant array producing libraries you only support X, Y and Z (because they don't raise) or (2) add try excepts around your if statements?

Not sure if this PR is the best place to discuss this, but I started typing just before Ralf merged it, so will post here. Maybe an issue (with a follow up PR) is a better place?

[rgommers]

I think it's in practice a non-issue:

• Few classes of algorithms should actually need __bool__; it's basically only iterative algorithms (e.g. minimizers, fitting routines)
• For those that do need such iteration, they invariably already don't support lazy/graph algorithms - so I'd suggest simply documenting that fact in the relevant docstrings.