Improve structure of package-data and document

Our current implementation of packaging and code signing works, but there is some tech debt that adds complexity. And I think, creates confusion . These are some notes about how to clean it up. (It's extracted from a private conversation in https://github.com/osquery/osquery-codesign/pull/28 and slack)

At a high level, our process is along the lines of:

1. osquery build produces binaries and packaging control data. This is distributed as package-data
2. codesign build signs binaries, and app bundles
3. codesign build uses the packaging scripts to package into various distribution formats
4. codesign build signs packages

But, I think the structure of package-data is confusing. For example, in macOS, package data contains both package_data/opt/osquery/osquery.app and package_data/opt/osquery/bin/osqueryd, this is because we want to sign and distribute both of those. However, they should never both appear in a package, and encoding them into the opt path there implies that's distributable, which is wrong.

I think that either package-data should match the final package structure, or it should be an arbitrary internal structure. When it mostly matches the final package I think it's very easy for us to make mistakes.

Thus, I propose package-data become more arbitrary. It should not contain the install directory path. I think it's okay to be messy -- it's an internal API between our build stages.

Start by reviewing the package_data/opt/osquery/osquery.app and package_data/opt/osquery/bin/osqueryd paths alongside the packaging scripts described in the issue. Compare the current package-data layout with the four-stage build and signing process; done means the internal structure no longer implies an install path and its intended use is documented.