Fixes item_id For Versions Migration

[jswright61]

Added 'limit: 8' as an additional parameter to the item_id field for the versions table. Bigint is the current default datatype for the id column of Rails tables and a reasonable choice for non Rails projects. This change allows id values to be properly stored when they would exceed the range of a 4 byte integer datatype.

Check the following boxes:

• Wrote good commit messages.
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Added an entry to the Changelog if the new
  code introduces user-observable changes.
• The PR relates to only one subject with a clear title
  and description in grammatically correct, complete sentences.

[jswright61]

This is my very first PR, so please be gentle. Honestly they probably don't get much simpler than this.

The item_id being a 4 byte integer cause an out of range error when I made a change to a record on a table tracked by paper_trail:
ActiveModel::RangeError: 918464985025609734 is out of range for ActiveModel::Type::Integer with limit 4 bytes

I'm storing some Twitter data and decided to use the id from the Twitter User instead of an incremental id for each record. It probably would have been quite a while until I discovered this issue had I been using sequential ids starting from 1. I can only guess that people are not using this gem on super huge tables which is why nobody noticed or fixed it before.

[jaredbeck]

Hi Scott,

This is my very first PR ..

Nice work!

Bigint is the current default datatype for the id column of Rails tables ..
[Example:] the id from the Twitter User ..

Makes sense to me, seems like a good example.

Unrelated to this PR, @seanlinsley and I have discussed increasing the size of versions.id also.