Add the ability to open the "last" checkpoint in the object, whether named or unnamed.

Michael comments:

> ... what I still think are the natural semantics for checkpoint:

• one application thread periodically calls checkpoint without specifying a name or worrying about what other application threads are doing;
• other threads can open a cursor on the most recent checkpoint (which will be unnamed);
• taking a new checkpoint drops any old unnamed checkpoints that are not open.

Adding the ability to open the last checkpoint in the object should allow this semantic.

If an application attempts to take an unnamed checkpoint while there's a cursor open on a previous unnamed checkpoint, the call will succeed (although the unnamed checkpoint where the cursor is open won't be deleted). This is relatively straight-forward: if we attempt to get a handle lock for an unnamed checkpoint, and fail, then we clear all delete flags for all existing checkpoints with that name, and continue. If a user attempts to take a named checkpoint while there's a cursor open on a previous named checkpoint, the call will continue to fail, as it currently does.

There's a little oddity here: if an application opens the "last" checkpoint in the object and it's named, then a subsequent checkpoint that has the same name will fail and a little oddly, since the application didn't specify the name to the cursor open explicitly. I think this is unlikely to happen: