Telling a representer to represent nil adds all of that class's methods to nil

The code causing this behavior is https://github.com/ruby-grape/grape-roar/blob/master/lib/grape/roar/representer.rb#L10

Example

user = User.find_by(email: 'i_dont_exist@gmail.com')
# user => nil
present user, with: User::Representer
# User::Representer.ancestors => [..., Grape::Roar::Representer, ...]

Obviously there's a bug in this application code, but the result is that, since nil is a singleton, now every time the application asks for nil, it gets it, but with all kinds of fun stuff mixed in, like a custom #to_hash that, for instance, mucks with the instantiation of ActionController::Parameters and causes completely unrelated pages in an app to blow up

Thoughts? I'd be happy to submit a PR, but i only have a cursory understanding of all the interplay between grape, roar, grape-roar, representable, etc. and just tossing in a nil check might not be the best approach

Start with lib/grape/roar/representer.rb at line 10 and reproduce the example where presenting nil changes User::Representer. Read the surrounding representer behavior and the issue discussion before deciding how nil should be handled. Done means nil is not modified with representer methods and unrelated uses of nil no longer exhibit the reported side effects.