Allow microvm configuration from a single json passed as command line parameter

[lauralt]

Issue #923 , if available:

Description of changes:
Added extra parameter 'config-file' to Firecracker, which allows starting a microvm without sending API requests. User has to send in the start command a file which stores a single json, that contains the configuration for all of the resources used by the microvm. Also, added an integration test which successfully starts a microvm with a configuration file sent as command line parameter and unit tests.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[acatangiu]

Changes LGTM for supporting the single json config from command line.

I'm a bit worried that we're missing a good opportunity to share the relevant parts with our API path so that we also support single API call config.
I believe clients that still need the API (e.g. for post-boot operations) would be highly grateful if they could do the single API call using their existing path (swagger-generated API client) instead of having to manually create JSONs and pass them as command-line args.

[alxiord]

I forgot about the changelog again! This is a big change, so please update all the relevant docs:

• add an entry in CHANGELOG.md
• add an entry in FAQ.md
• update jailer.md with the new parameter
• add a section in getting-started.md#running-firecracker

I also totally forgot about the swagger spec and wouldn't have remembered if @acatangiu hadn't mentioned it. Customers can use it to autogenerate clients, so it should support the new payload format.

[alexandruag]

I'm a bit worried that we're missing a good opportunity to share the relevant parts with our API path so that we also support single API call config.
I believe clients that still need the API (e.g. for post-boot operations) would be highly grateful if they could do the single API call using their existing path (swagger-generated API client) instead of having to manually create JSONs and pass them as command-line args.

That's a good point, but a bit outside the scope of this PR. The opportunity to build on top of this remains, and we can prioritize it if there's a real customer need, or pick it up as follow-up work at some point.

[acatangiu]

I agree that we needn't target the single API call config in this PR, but I think that @lauralt has a good opportunity to do that as well (in subsequent PR/PRs) - it has real customer value.