Adding a usage message to install.rb script

Previously, invoking the install.rb script with zero arguments
caused it to attempt to install all gems without a version
suffix, which would fail spectacularly. Failing gracefully with
a usage message is more helpful to a first-time user.
Merge pull request #8729 from timraymond/help_message_for_install_script

Adding a usage message to install.rb script
move error page js into script tag
Fix missing spaces before and after equal signs in method definitions
Merge pull request #8730 from robin850/master

Fix missing spaces in method definitions
update directory tree in the generated README
Add documentation to ActionDispatch::Http::UploadedFile#headers

[ci skip]
Merge pull request #8731 from amatsuda/readme_dir_tree

update directory tree in the generated README
no, call <%= yield %>
Merge pull request #8732 from amatsuda/readme_call_yield

a tiny fix in the generated README
Fix undefined method `to_i' introduced since 3.2.8

This commit fixes a bug introduced in 96a13fc7 which breaks behaviour of
integer fields.

In 3.2.8, setting the value of an integer field to a non-integer (eg.
Array, Hash, etc.) would default to 1 (true) :

    # 3.2.8
    p = Post.new
    p.category_id = [ 1, 2 ]
    p.category_id # => 1
    p.category_id = { 3 => 4 }
    p.category_id # => 1

In 3.2.9 and above, this will raise a NoMethodError :

    # 3.2.9
    p = Post.new
    p.category_id = [ 1, 2 ]

    NoMethodError: undefined method `to_i' for [1, 2]:Array

Whilst at first blush this appear to be sensible, it combines in bad
ways with scoping.

For example, it is common to use scopes to control access to data :

    @collection = Posts.where(:category_id => [ 1, 2 ])
    @new_post = @collection.new

In 3.2.8, this would work as expected, creating a new Post object
(albeit with @new_post.category_id = 1). However, in 3.2.9 this will
cause the NoMethodError to be raised as above.

It is difficult to avoid triggering this error without descoping before
calling .new, breaking any apps running on 3.2.8 that rely on this
behaviour.

This patch deviates from 3.2.8 in that it does not retain the somewhat
spurious behaviour of setting the attribute to 1. Instead, it explicitly
sets these invalid values to nil :

    p = Post.new
    p.category_id = [ 1, 2 ]
    p.category_id # => nil

This also fixes the situation where a scope using an array will
"pollute" any newly instantiated records.

    @new_post = @collection.new
    @new_post.category_id # => nil

Finally, 3.2.8 exhibited a behaviour where setting an object to an
integer field caused it to be coerced to "1". This has not been
retained, as it is spurious and surprising in the same way that setting
Arrays and Heshes was :

    c = Category.find(6)
    p = Post.new

    # 3.2.8
    p.category_id = c
    p.category_id # => 1

    # This patch
    p.category_id = c
    p.category_id # => nil

This commit includes explicit test cases that expose the original issue
with calling new on a scope that uses an Array. As this is a common
situation, an explicit test case is the best way to prevent regressions
in the future.

It also updates and separates existing tests to be explicit about the
situation that is being tested (eg. AR objects vs. other objects vs.
non-integers)
Merge pull request #8734 from jstirk/master-column_writer_to_i_errors

Fix undefined method `to_i' introduced in 3.2.9
No such feature in Rails anymore. That's Bundler's business

[ci skip]
Change duplicated test name
Reuse the Column integer converter
Bump bundler dep to 1.3.0.pre.4+ to introduce 'bundle binstubs <gem>'
Use bundler --pre for travis builds
Added ability to compare date/time with infinity

Date, DateTime, Time and TimeWithZone can now be compared to infinity,
  so it's now possible to create ranges with one infinite bound and
  date/time object as another bound.

  Ex.: @range = Range.new(Date.today, Float::INFINITY)

Also it's possible to check inclusion of date/time in range with
  conversion.

  Ex.: @range.include?(Time.now + 1.year) # => true
       @range.include?(DateTime.now + 1.year) # => true

Ability to create date/time ranges with infinite bound is required
  for handling postgresql range types.
Merge pull request #7350 from slbug/date_time_ranges_with_infinite_bounds

Added ability to compare date/time with infinity
Remove assert_nothing_raised