Speed up pry require with autoloading

[gmcgibbon]

👋 I noticed pry-rails was taking a little while to load during boot time of my app:

This is because it loads pry and pry-byebug. However, the bulk of the time is spent loading pry itself. I thought using autoload and some lazy evaluation could speed up the load time for the library. I also added the following optimizations:

• Lazy initialization for Pry::Config (because previously it was being created in Pry.init which would load most of pry at require time).
• Move Pry::Command::Ls::DEFAULT_OPTIONS to Pry::Config::DEFAULT_LS_OPTIONS (the constant didn't seem to be used by the Ls command class, so it made more sense to include in Pry::Config to avoid loading commands early).
• Put all commands in pry/commands and require it on initial session load. This might not be the most ideal solution, but the command classes shouldn't need to be loaded until pry is started.

You can verify the speed improvement with a simple benchmarking script:

require "bundler/setup"
require "benchmark"

ms = 1000 * Benchmark.realtime do
  require 'pry'
end

puts "Took #{ms}ms to load."

Before the patch, this took about 100ms, and now it is down to ~20ms. If this is a good direction for pry, I'd also like to change pry-rails to delay loading its commands. This require seems unnecessary when there's one already in the console block of the railtie.

[gmcgibbon]

Regarding the test failure, it appears to be a bundler bug. The bundler version on CI wipes pry from $LOAD_PATH after the inline gemfile (which breaks autoload). Updating bundler or making the autoload paths absolute would work, but I'll wait for feedback before fixing that.