* move maps of plugins back in core

* go mod vendor

* more fixes

* fix imports

* Update core_test.go

* fix build

* more fixes

* more fixes

* up vendors after fixing sdk

* Update post_processor_mock.hcl2spec.go

* Leave implementatino of MapOf in the sdk for plugi tests

Other wise use the interface

* go mod tidy

* add MapOfDatasource type too

This add :
* discovery of `packer-plugin-*` binaries from the known folders and ask them to describe themselves
* tests

For testing: in go we create a bash script that in turn calls back to Go. I could not make the tests to work on windows and then would like to postpone testing this for when we know more about the finite layout of this feature. That is mainly: how things are going to work with init, versioning and such.

os.Executable is available since go1.8
https://github.com/kardianos/osext/blob/master/osext_go18.go

make period stripping more strict so that users can disable provisiners by adding .old or whatever; this is pretty typical convention.

Before this change loading of a packerconfig would display `loaded
plugin ...` for any plugin defined in the packerconfig - even if it
didn't exist on disk. This change updates how plugins defined in
packerconfig are loaded to ensure that only successfully loaded plugins
get the lovely message `loaded plugin ...`. For any plugin that fails to
load Packer will log that it failed to load the plugin and continue
processing any other defined plugins.

* Add a test to ensure loadSingleComponent errors when plugin does not
exists

This change introduces a loadExternalComponent which can be used for
loading a single plugin path. The function is a combination of
the discoverSingle and discoverExternalComponents functions.

This follows #8232 which added the code to generate the code required to parse
HCL files for each packer component.

All old config files of packer will keep on working the same. Packer takes one
argument. When a directory is passed, all files in the folder with a name
ending with  “.pkr.hcl” or “.pkr.json” will be parsed using the HCL2 format.
When a file ending with “.pkr.hcl” or “.pkr.json” is passed it will be parsed
using the HCL2 format. For every other case; the old packer style will be used.

## 1. the hcl2template pkg can create a packer.Build from a set of HCL (v2) files

I had to make the packer.coreBuild (which is our one and only packer.Build ) a public struct with public fields

## 2. Components interfaces get a new ConfigSpec Method to read a file from an HCL file.

  This is a breaking change for packer plugins.

a packer component can be a: builder/provisioner/post-processor

each component interface now gets a `ConfigSpec() hcld...

* Added conversion to template without timeout
* Added timeout
* Extracted converting to template to a separate step