Package JSON manifest should support generic attributes

[nacl]

I like the idea of the JSON manifest format -- it allows us to create backends for a generic packaging frontends.

I would like to adopt this for pkg_rpm at some point, but in order to do this, the manifest would need to support a generic "attributes" format to support file tags (like %config). This will also be needed for supporting packages in Windows.

So, instead of separate mode, user, and group fields, perhaps we should have an attributes object that can contain arbitrary information, mirroring pkg_attributes in the pkg_filegroup framework?

[aiuto]

We can do whatever we want. Since there is, so far, 1 method that writes the manifest, and one that decodes an entry, and they are both private interfaces, changing the format is fair game as we need it.

Another reason for moving to that now might be that we may have to add more user/owner types for #370 . Rather than add more fields at the top level, add them to the embedded struct.

[aiuto]

One more requirement: We need operators around this

• combine - which combines two attribute sets. For example, one has owner + group and the other has mode, yielding one with owner, group, & mode.
• compare for equality. - when we have the same file put in an archive twice, that is fine if the modes are the same. If the modes conflict, it should raise an error.

[nacl]

Been thinking about this on and off. Initial thoughts:

• The manifest is a JSON array containing a series of objects. Each object represents an individual installable entity, as is known by Bazel. Each key represents an attribute of the entity, each value represents the value of that attribute.
• Each entity type is represented by a type field (a string or enumerated value). This type dictates how the "core" attributes are interpreted.
• "Core" attributes include things like sources, in-package destinations, basic UNIX-style permissions (either octal or strings), and UNIX-style ownership.
• "Extended" attributes are related to specific entities (e.g. properties of UNIX-style device nodes), or specific packaging rules (e.g. Windows installers, or custom file tags in pkg_rpm)

So, something like this:

[
  {
    "label": "//:foo-config",
    "type": "FILE",
    "source": "bazel-out/k8-linux-fastbuild/foo", // or whatever bazel provides us
    "destination": "{PREFIX}/etc/foo", // Templated destination
    "mode": "rw-r--r--", // or 0644
    "user": "root",
    "group": "root",
    "rpm_filetag": "%config" // Custom attribute for pkg_rpm
    "zip_compression": "STORE" // Theoretical custom attribute for pkg_zip
    "unix_extended_permissions": "+i" // Theoretical custom attribute for UNIX-style installers (set immutable bit) 
   },
   ...
]

This is simple enough to meet all the above requirements and is also relatively futureproof. It also has the unfortunate consequences of requiring more code and redoing a bit of the logic that we already have for the manifest system as used in pkg_zip and pkg_tar. WDYT?