Rw/refactor associations

### What's this PR do?

1. I refactored the associations to make it more obvious what information was relevant to a Seller and what was relevant to a Buyer. Now things like `InitialApplication`, `Financials`, `DebtorTerms`, `Debtor`, `Invoice`, `Auction` all go through the `User`'s polymorphic account association, `Seller`, which I think makes sense since these concepts are only relevant to a seller. `Bid` is now an association on `Buyer` too. Prior to this all the associations were on `Company`, and I thought to remove it, but turns out it's quite useful to see all this info through company in the admin dashboard.

2. `spec/factories.rb` got a complete makeover, thanks to @georgebrock's suggestions and the FactoryGirl docs. I have taken advantage of traits to keep everything clean and the setup in many of the feature specs are much better for it.

3. Added presence validations for each Class of object and adjusted `factories.rb` accordingly. 

4. Changed `AuctionBuilder` to `AuctionFactory` and did a small refactoring.

5. Updated DB columns on `Auction` to make use of Decimal column instead of Float to represent a percentage.

### Where should the reviewer start?

1. Please see `spec/factories.rb` to see the improvements! Take a look at the diff in `spec/features/seller_creates_auction_spec.rb` as an example.

2. See `app/services/auction_factory.rb` to check if this is an appropriate use of the Factory pattern.

### Any background context?

The setup in my specs were becoming more difficult to write and maintain, and after suspecting this was a code smell, I asked George and got some good tips on how to make the most out of FactoryGirl using traits and inheritance. The result is much cleaner test setup in most of my specs. 
Align the parameters of a method call if they span more than one line.