Select nil value if passed nil option and no explicit :selected value

I had a model with an attribute that could have either a nil or a non-nil value, and in the database one record's value was nil while others' werent. I was surprised that when doing something as following (simplified example):

```erb
<%= form_for @my_model do |f| %>
  <% select_options = [ ['Nothing', nil], ['Foo', 'foo'], ['Bar', 'bar'] ] %>
  <%= f.select :my_attr, select_options %>
<% end %>
```

The 'Nothing' option was *not* selected if `@my_model.my_attr` was nil, yet other options were selected fine if the model had the matching value. This **bit** me because it (silently) didn't select the currently saved value from the dropdown, so a user who opened a form for edit and saved it without even touching the dropdown, would overwrite selected value (from nil to whatever happened to be first option in the dropdown) without ever knowing it!

Since the `select` helper silently casts a `nil` option value to an empty string (instead of, say, raising a nil object error), I expected that it would also be able to match it against a nil attribute for the selected element.

This PR fixes this by casting the implied `:selected` option to be an empty string, so it correctly finds a matching empty option. 

I also added a second regression test to ensure that an explicitly passed `:selected => nil` is not treated like empty string (to preserve existing behaviour documenting that `:selected => nil` forces no option to be selected. I realize this may be a discrepancy, because `f.select :my_attr, select_options` will now behave differently than `f.select :my_attr, select_options, @my_model.my_attr` (if `@my_model.my_attr` returns nil), but I still think it's less surprising than current behaviour.

The other potential issue I see is that if someone has both a nil and an empty string as select options, and selected value is empty string, they both will now be marked as selected (previously, only empty string would be). I'm not sure this is a significant use case. It would be simpler to fix if we don't need to distinguish between explicit and implicit `:selected` - if we do, I think the `options_for_select` or `extract_selected_and_disabled` methods might have to be refactored instead.