Establish sentinel value for Importer.Import's "importedFrom" parameter

[seh]

Per preceding discussion in vmware-archive/kubecfg#266, the Importer.Importer method's "importedFrom" parameter is not documented at present, and interpreting its value varies by Importer implementation. When importing values for external variables and TLAs, though, such as for files nominated either by the --ext-str-file, --ext-code-file, --tla-str-file, and --tla-code-file flags or in the value of the --ext-code or --tla-code flags, the "importedFrom" location is best thought of as "the top-level context of program," which often means the current working directory.

In order to allow Importer implementations to detect these special importing scenarios, @sbarzowski proposed replacing the current sentinel values passed as arguments for the "importedFrom" parameter (e.g. <extvar:example>) with the empty string, per vmware-archive/kubecfg#266 (comment). Not just that, but we would also document this contract as part of the Importer interface, so that all Importer implementations could count on receiving this value to trigger their own interpretation of "this path is being imported in the top-level context."

The pending vmware-archive/kubecfg#271 shows an Importer implementation that depends upon this proposed contract.

[seh]

In the current implementation, function prepareExtVars in file interpreter.go prepares the current pseudo-file names like <extvar:example> and passes them down through the the code-to-AST gullet. It's useful to have these indicative placeholders available in some places for diagnostic clarity, but we need to be able to tell later that they're not actual file paths. Hence, we could consider expanding program.SnippetToAST to take an additional parameter that distinguishes between the source "file name" (again, not always nominating a real file) and the value suitable for passing to Importer.Import's "importedFrom" parameter.

Changing the signature of the exported function program.SnippetToAST is not nice for existing callers, but program is an internal package, so I think we do have that freedom.

[seh]

Though not directly related to the proposal here, @sbarzowski also noted that these top-level imports from these pseudo-files should not be cached (vmware-archive/kubecfg#266 (comment)).

[sbarzowski]

Though not directly related to the proposal here, @sbarzowski also noted that these top-level imports from these pseudo-files should not be cached (vmware-archive/kubecfg#266 (comment)).

To be clear, I just meant that the ExtVars themselves should not be part of the import cache (it was a bit hacky in retrospect to use the same mechanism for extvars and for imports). If something is imported from extVar/TLA using import or importstr it should be cached normally.

[seh]

See #447 for a supporting solution.