meta.sourceProvenance is unaffected by changes to meta.license

This commit clarifies that the meaning of the `meta.sourceProvenance`
field is independent of and unaffected by the value of the
`meta.license` field.  This is based on the intent of the RFC author
as expressed here:

  #161098 (comment)

This clarification is added for two reasons:

1. If in the future there should be some disagreement about what
   `sourceProvenance` to assign to a package, this may help resolve
   the disagreement.  Any interpretation of `sourceProvenance` which
   is influenced by the `meta.license` is clearly an incorrect
   interpretation.

2. If it should turn out that it is impossible to disentangle
   `sourceProvenance` from `meta.license`, this would indicate the
   need for changes to the `sourceProvenance` scheme.  That change
   might be as simple as replacing the sentence added by this commit
   with some other sentence explaining how the two fields influence
   each other.

This commit implements the recommendation made in the paragraph of
this comments which begins with "Please say this explicitly...":

  #161098 (comment)

doc/stdenv/meta.chapter.md

@@ -226,6 +226,8 @@ Adding this information helps users who have needs related to build transparency
 
 The presence of a particular `sourceType` in a package's `meta.sourceProvenance` list indicates that the package contains some components falling into that category, though the *absence* of that `sourceType` does not *guarantee* the absence of that category of `sourceType` in the package's contents. A package with no `meta.sourceProvenance` set implies it has no *known* `sourceType`s other than `fromSource`.
 
+The meaning of the `meta.sourceProvenance` attribute does not depend on the value of the `meta.license` attribute.
+
 ### `lib.sourceTypes.fromSource` {#lib.sourceTypes.fromSource}
 
 Package elements which are produced by a nixpkgs derivation which builds them from source code.