Support UUID Model ids

[KelseyDH]

UUID's are a popular strategy for model id's due to their unique properties across all tables. Unfortunately it appears that this gem does not support uuid's natively, owing to a 17 strong character letter limit on scope objects id.

This can be seen with the following test, which will fail:

    it 'finds account by uuid' do
      object_with_uuid = double(:id => 'fea45df8-2ec0-4e8d-9c5a-5871a5414bca')

      expect do
        DoubleEntry.account(:savings, :scope => object_with_uuid)
      end.to_not raise_error

      expect do
        DoubleEntry.balance(:savings, :scope => object_with_uuid)
      end.to_not raise_error
    end

Which if run will result in this failure showing the problem:

=>      Failure/Error:
       expect do
         DoubleEntry.account(:savings, :scope => object_with_uuid)
       end.to_not raise_error
     
       expected no Exception, got #<DoubleEntry::ScopeIdentifierTooLongError: scope identifier 'fea45df8-2ec0-4e8d-9c5a-5871a5414bca' is too long. Please limit it to 23 characters.> 

with backtrace:
         # ./lib/double_entry/account.rb:167:in `ensure_scope_is_valid'
         # ./lib/double_entry/account.rb:108:in `initialize'
         # ./lib/double_entry/account.rb:27:in `new'
         # ./lib/double_entry/account.rb:27:in `account'
         # ./lib/double_entry.rb:44:in `account'
         # ./spec/double_entry_spec.rb:417:in `block (4 levels) in <top (required)>'
         # ./spec/double_entry_spec.rb:416:in `block (3 levels) in <top (required)>'
     # ./spec/double_entry_spec.rb:416:in `block (3 levels) in <top (required)>'

Instead, double_entry implemention should support both sequential ids and uuid's -- the big benefit with UUID's being we no longer need to worry about the validity of id values and what model its associated with. This makes it easy to use double_entry in outside contexts, like consuming the ledgers of external systems where account objects are represented as api keys or other arbitrary string values.

[swrobel]

A search would've revealed this has been discussed before: #100

[orien]

Yes, one can customise the database column constraints. Both the length of strings and the size of integers. Although I understand the reluctance to deviate from what's provided by default.

Perhaps we should move the default to be most accomodating: 255 character strings and 64 bit integers. Applications can then choose to impose a stricter constraint if they so choose.