feat: Include setup key in published Orb examples

[adamdmharvey]

Signed-off-by: Adam Harvey [email protected]

This PR is intended to at least partially address address #779.

Checklist

=========

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have checked for similar issues and haven't found anything relevant.
• This is not a security issue (which should be reported here: https://circleci.com/security/)
• I have read Contribution Guidelines.

Changes

=======

• Includes the YAML setup key in the packed orb examples, so if an orb author wants to recommend to users to require the use of dynamic pipelines, this example is sent as is to the end user.
• Adds a test to specifically check for this key.

Rationale

=========

I opened a CircleCI Support ticket after we noticed we published examples to some of our users in private orbs, and when they were copying the examples they kept not working. WE realized the setup: true key which triggers a dynamic pipeline (allowing the use of the continuation orb, etc) was being filtered out when our examples were being published to the CircelCI web site.

Support spun my ticket out to #779 and closed the support ticket. @KyleTryon was kind enough to point to the code schema where the setup key did not exist.

Considerations

==============

The orb packing test suite is a bit brittle at the moment. So without entirely rewriting it with a much more comprehensive example, I took what was there, slightly simplified the test for an included script which should still make sure that test is valid, but also considers if the pack section slightly reorders the keys, as well as adds a test for my new functionality.

I'd think over time, getting a detailed packed example, possibly put into the repo with samples of commands, jobs, executors, examples, etc, might be worthwhile over time. But not today!

Screenshots

n/a

Here are some helpful tips you can follow when submitting a pull request:

1. Fork the repository and create your branch from master.
2. Run make build in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (make test).
5. The --debug flag is often helpful for debugging HTTP client requests and responses.
6. Format your code with gofmt.
7. Make sure your code lints (make lint). Note: This requires Docker to run inside a local job.

NB: Local go testing now goes clean for me, so submitting the PR.