Improve require-time latency

[countvajhula]

@sarna reported on Discord that startup time is on the order of hundreds of milliseconds. They suggested this way to test it:

base.rkt:

#lang racket/base

(displayln "hey!")

qi.rkt:

#lang racket/base

(require qi)

(displayln "hey!")

After running raco setup to ensure that Qi is compiled, the results are:

$ time racket base.rkt
hey!

real	0m0.270s
user	0m0.134s
sys	0m0.085s

$ time racket qi.rkt
hey!

real	0m0.812s
user	0m0.661s
sys	0m0.141s

Ways in which users could improve it

Suggestions from @Bogdanp:
"[There's not much you can do] apart from ensuring those [...] are compiled (by running raco setup). lazy-require may help if some of the work can be deferred, and raco demod might help, too, depending on how often you run the code (raco demod takes a while to run and it doesn't work in all cases)."

"If this is for a CLI tool, then I'd recommend raco demod + raco exe
raco demod foo.rkt && raco exe -o foo foo_rkt_merged.zo"

Ways in which the library could improve it

@jackfirth suggests:
"using #lang racket/base instead of #lang racket helps
but options are limited
it's a problem that really needs some VM work to solve"

Qi already does use #lang racket/base in all modules (except in test modules, but I don't think that would matter here) but worth double checking. Also, once the core language is available (#49 ), Qi should be able to provide something analogous to racket/base, like qi/base, with the option to include additional functionality via separate requires just like in Racket.

Bogdan suggests:
"I think the best library authors can do is depend on less code and write macros that generate minimal amounts of code (i.e. write helper functions and have macros expand to calls to those functions instead of generating the same code over and over). Depending on a subset of a module won't help, but restructuring modules such that less code is loaded overall can."

This can definitely be explored. I didn't really consider this kind of thing before so it's likely there can be some quick gains here.

[countvajhula]

Fixed by #51 , which resulted in a significant improvement in require-time latency. There are still other things to try in the suggestions above which could be explored down the line, but for now I think this issue can be considered solved.