Rework node provenance for synthetic nodes

[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/1058)
In GitLab by [[Gitlab user @BenjaminSchubert]](https://gitlab.com/BenjaminSchubert) on Jun 28, 2019, 09:57

Related to !1425 (https://gitlab.com/BuildStream/buildstream/merge_requests)/1425#note_186387325)

There are only two cases were nodes are set in the code (hence without provenance):
- When automatic variables are set by the core (e-g: max-jobs)
- when plugins call Element.set_public_data

The first case should never throw errors, so it is of limited interests.
The second is more important. What should probably be done here is to have 'set_public_data'
able of creating a fake provenance with the name of the plugin, the project and probably the element name.

Currently, we get the provenance from the element file, which does not contain the data.

We would therefore have much better error messages, and would be able to get rid of most synthetic nodes.

Start with Element.set_public_data and the core path that sets automatic variables; compare their current provenance with the element-file provenance described in the issue. Read the original GitLab issue and related !1425 for context, then define completion as plugin-created public data producing useful provenance and error messages while reducing synthetic nodes.

Written by the indexing model from the issue text.