Make macOS package and tgz naming consistent

[Smjert]

It has been brought to my attention that the macOS tgz we create, containing the artifacts needed to create a .pkg, recently changed the architecture name from x86_64 to arm64, due to how the CI was creating them.
Both architectures are wrong, because the binary inside it's actually a universal one.

Looking at how we name things though I see another inconsistency. The naming format for macOS artifacts has been copied from Linux, so the macOS common.make has the following scheme:

osquery-packaging/platform/macos/common.cmake

Lines 10 to 11 in c089fb2

	set(OSQUERY_PACKAGE_RELEASE "1.macos")
	set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}_${OSQUERY_PACKAGE_RELEASE}_${CMAKE_SYSTEM_PROCESSOR}")

But it's being overriden in the productbuild (or .pkg) case with:

osquery-packaging/platform/macos/productbuild.cmake

Line 10 in c089fb2

set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}")

So in the end that naming only works for the .tgz. I think that we should decide a consistent naming scheme.

On the one hand it makes sense to me to have a package release component, in all cases, to indicate that the package has been recreated with the same contents (maybe there was an issue with the CI that created the package or what not).
I'm not sure if we ever used it though, since the package creation is all pretty automatic.

For the architecture, I was initially thinking of putting universal as default for the architecture, and then let the user manually set a custom architecture if they wanted, but adding an option only for the tgz (or any other method that is not .pkg) felt weird. Mostly in how would we even name that.
If the architecture appeared in all the artifacts, then it would make more sense.
Another alternative is to simply remove it and not let the user change it (without modifying the cmake). This would assume that the package is a universal one, and so always works wherever it's being installed.