Add a new per-session flag, WT_SESSION_CAN_WAIT

@michaelcahill, here's the change we discussed, plus a couple of semi-related odds-and-ends (all on separate commits, so you can cherry-pick or revert easily if you want).

Reference #1152.
Thanks for the explanation. I understand now. I'm not entirely sold on the reasoning though - I don't think the flag should be set here because I think we still care how long the checkpoint lock is held for. The particular scenario I'm thinking of is:

An application has some non-LSM tables and a couple of LSM trees, has configured logging on and regular checkpoints (so log files can be archived). If application or WiredTiger checkpoint server checkpoints hold the checkpoint lock for a long time, that will stall LSM trees because they need to take the checkpoint lock to flush chunks.

Now that I've constructed my use case, maybe it's too complex to be concerned about?