Hierarchical pkg_filegroup implementation mockup (try 2)

[nacl]

This change is intended to start a discussion on how we might make a "nestable" pkg_filegroup rule, as @aiuto mentioned in the review for pkg_mklinks.

The mechanism for calling rules out in other rules was tested and is known to work, but I wonder about what to do with the name attribute.

A thought that comes to mind is that pkg_file could emit a specification that a (currently nonexistent) pkg_filegroup rule could use to provide a name to a "real" pkg_file rule (or however it is implemented).

This is a duplicate of #212 that could not be reopened or edited after the master branch was deleted.

[nacl]

Transplanting the last major discussion point:

@aiuto in #212 (comment) said:

Collisions to the final destination path of a package should fail hard. It is the most straightforward thing we can do.
A single input, however, can be mapped to multiple destination paths in the enclosing package.

You're right that pkg_filegroup is a strange name. bug pkg_dir is a misnomer too, because it can include things globed in from subdirs. It is occuring to me that we should brainstorm on this in a shard document rather than trying to make code work. A meeting room and a whiteboard would help too.

The big questions.

* what expresses existing use cases in an easy to understand way

* how do we re-root things in a natural manner

* is the pkg_file inside the pkg_filegroup too extreme.   I would like to show that to a broader community than just us.
  pro:  It is a readable way of expressing a structured attribute.
  con: no one else does this.  It means pkg_filegroup MUST be a macro rather than a rule.

I think the pro outweighs the con, but I am not sure. This might not even be legal syntax for Starlark.

[nacl]

Discarding in favor of #273 and future related changes