RFC: role-based packaging system

The implementation of the `pkg_filegroup` framework relies upon users specifying specifically where files end up in packages. It is up to the user to create the various `pkg_files` rules to manage this. This is great for general-purpose use, but can be quite verbose.

One idea for reducing verbosity is to specify package contents in terms of tables, like in #238. That, however, still relies on manual path construction and placement. Another way to specify this is to identify files in terms of their roles, namely what they're intended to do: e.g. configuration files might be installed in one location, binaries another, and libraries another from that.

We can imagine a system by which could associate a "role" with a particular target or target outputs. For example:

```python
cc_binary(
name = "binary",
srcs = [...],
tags = ["role-binary"],
)

cc_binary(
name = "support-binary",
srcs = [...],
tags = ["role-support-binary"],
)

cc_binary(
name = "library",
srcs = [...],
tags = ["role-library"],
)

pkg_role(
name = "role-binary",
prefix = "/usr/bin",
identifiers = ["role-binary"],
)

pkg_role(
name = "role-support-binary",
prefix = "/usr/libexec/foo",
identifiers = ["role-support-binary"],
)

pkg_role(
name = "role-library",
prefix = "/usr/lib",
identifiers = ["role-library"],
)

pkg_role_filegroup(
name = "installed-data",
srcs = [
":binary",
":support-binary",
":library",
],
roles = [
":role-binary",
":role-support-binary",
":role-library",
],
)

pkg_rpm(
name = "rpm",
srcs = [":installed-data"],
...
)
```

`pkg_role` would emit a provider that would inform `pkg_role_filegroup` about the nature of a role, in this case, where files end up, and what identifier (`tag`) should be used to inspect them. This information would be accumulated in an aspect and then processed to form a `PackageFilegroupInfo` provider that can then be passed to packaging rules as needed.

This simplifies the package implementaiton process by allowing users to associate packaging information with the rules that emit the outputs in question, at the cost of granular control. Information regarding destinations and other policies could be encoded into `pkg_role`s by way of `select`s and other logic.

This also comes with the cost of complex implementation, testing. There are a considerable number of edge cases that would need to be considered, as well as distribution (e.g. roles should be standardized) . Should this feature be desired, a design document should be created, along with prototypes.