Find select2 when it's added asynchronously.

The scenario: press a button that (perhaps via AJAX) causes a select2
with a label to appear asynchronously. This test would fail:

    click_button('Make a Select2')
    select2('My Choice', from: 'The Newly Created Select2')

because the label isn't present immediately, and `first("label", ...)`
doesn't wait for the label to appear. `find` does.

This change will cause an error to be raised if there's more than one label
with the given text. The solution here is to limit the scope using
`within`, and/or use a selector instead of text to find the select2.
More robust if label and select2 aren't adjacent.

The previous code expected the select2 to be inside the innermost div
containing the label. That won't necessarily hold for all scenarios (for
example, the "Inline Labels" markup for Zurb Foundation). So now we use
the label to find the element that it gives focus to, and then search up
the DOM to find the select2-container.
Handle both single and multiple selects w/ Poltergeist.

In the single-select scenario, we clicked the "choice" element (to open
the dropdown), then clicked it again during the "values" loop. This
probably works on some Capybara drivers, but Poltergeist noticed that
the second time we tried to click, the choice element was obscured by
select2's dropdown mask.

There's no reason to click the choice element twice in the single-select
UI. But we do need to click it once for each value in the
multiple-select UI. So now we just check which UI is in use, and act
appropriately.

BTW, we do the single-select click *before* we enter the search term. I
suspect search doesn't work in the multiple-select UI, but it didn't
work before this change, either.
More methods for working with a select2.

Useful for examining the select2's current state.

It would probably be better to have a single method

    expect_select2('Expected Value(s)', from: 'My Select')

but I haven't done that yet.