Enhance --stats option

[makenowjust]

This pull request adds a statistic of the last process of some crystal sub-command (i.e. built binary execution time for crystal run, calculation time for crystal tool implementation, etc...)

It is useful to distinguish real execution time from parsing time, processing AST time and generation binary time in one shot.

[makenowjust]

Wow. unknown ci failure again!

[RX14]

Looks like the specs hang on travis once in a while. Probably a good idea to enable outputting of full spec names to work out if it's a specific spec each time.

[asterite]

@RX14 I thought of doing the same. LET'S DO IT! 😸

[asterite]

d20f420 :-)

@makenowjust Do you want to rebase against master? That way the specs will run in verbose mode and we could see if they stall in a specific one.

[makenowjust]

@asterite Rebased!

[asterite]

@RX14 Cool! The first build with verbose specs failed, and it stopped at "Thread::ConditionVariable", which seems like a good candidate to stop everything :-)

[asterite]

I think I'll just mark the condition variable specs as pending for now, as they aren't used anywhere in the code. We can wait until we need them (if we'll need them) when adding support for parallelism. And in any case those specs weren't written by us so they might be buggy (for example, this pcond.signal has no matching pcond.wait, which makes me think there might be something wrong with that spec)

[asterite]

@makenowjust Thank you for this! This is super nice! I always wanted to compile + run + see execution time in one go but couldn't, so I end up compiling a binary and running it.

Maybe, just for crystal run and the usual crystal program.cr it would also be a nice idea to add a maybe -t flag (time execution) so that only the "Execute" part is shown after running the program. Probably most of the time you are interested in that and not in all of the compiler stages. What do you think?

In any case I'll merge this because it's very useful :-)

[makenowjust]

@asterite Yes. -t flag is nice idea!