Prototype for custom app loaders

[Morriar]

Motivation

Currently Tapioca is unable to generate DSL RBIs for applications that are not Rails applications.

This PR provides a way for the user to pass a custom loader so Tapioca can load the application then run the RBI compilers.

To do so, one can create a file under sorbet/tapioca/loader.rb with the following content:

Tapioca.load_for_dsl do
  print "Loading my custom application application..."
  require_relative "../../lib/post.rb"
  puts " Done"

  load_dsl_compilers
  require_relative "../../lib/compilers/some_custom_compiler.rb"
end

Tests

See automated tests.

[vinistock]

About the user experience, is there a simple way we could detect if the developer forgot to invoke load_dsl_defaults?

One idea I had, but that requires changing the interface, would be separating loading the app from loading custom compilers and having Tapioca deciding when to invoke load_dsl_defaults. E.g.:

Tapioca.eager_load_app do
  require ...
end

Tapioca.load_dsl_compilers do
  require ...
end

# And then, inside Tapioca
def execute
  instance_exec(&Tapioca.eager_load_app_block)
  load_dsl_defaults
  instance_exec(&Tapioca.load_dsl_compilers_block)
end

WDYT?

[paracycle]

I have 2 problems with this but I think we should merge the PR so that we can iterate on those separately:

1. I don't like the fact that we are basically exposing the Dsl command's surface area as a public API to the loader file. This will cause us problems down the line, since the command looks like an implementation detail to us devs, but will now be a public API where we can't change some method names/signatures anymore. Ideally, we would expose the surface area of a specific and custom object, something like a DslLoaderApi class or something.
2. I am not a fan of the DSL language we are building inside the loader and have similar concerns with @vinistock about how easy it might be to make people shoot themselves in the foot.

However, we can iterate on these, so LGTM.