Speed up app creation & reduce 3rd party shards when installing a fresh app

[crimson-knight]

Description

Amber has some lingering resources that are forks from 3rd party shards. It's time to switch back to using the shards that have been moved into the Amber Framework Org, and reassess/evaluate the 3rd party shards we forked to determine how to move forward with them.

Shards that are now in the org that don't need the outside forks any more:

• i18n (still under my user, having issues transferring into the org)
• Liquid.cr

Shards that are forks of others:

• CLI
• Optarg
• Teeplate
• json_mapping

[devnote-dev]

+1 for reducing third-party shards, however, command line parsing can be a tricky thing to implement, especially for a project as big as Amber. Can I suggest using Cling for parsing? It's a very modular CLI library designed to be scalable and easily configurable without requiring lots of boilerplate or awkward syntax. The actual library itself is only 9-10 files and has no dependencies, so no need to worry about issues with transitive dependencies.

[crimson-knight]

@devnote-dev The CLI lib we use now works fine covers everything we need, I've started moving it into it's own repo to be it's own tool separate from the main Amber app itself.

I think what I'll do is move the forked code into the repo for the new cli tool so there's no extra resources to grab and maintain.

[robacarp]

The Lucky org has a fork of teeplate that's been more recently maintained than upstream, and maybe even the one Amber uses. At any rate there's no reason to have two forks of it.