This is guaranteed to be called only once for a given session once the
sources are known to be Consistency.CACHED, if source tracking is enabled
in the session for this source, then this will only be called if the
sources become cached after tracking completes.

 o Unlisted submodule warning

   Now the git plugin will issue a configurable warning if a submodule
   exists and is used (checking out the submodule is not disabled),
   but is not specified in the source configuration.

 o Invalid submodule warning

   Now the git source plugin will issue a warning if the configuration
   specified a submodule which does not exist in the underlying git repository.

As a side effect, this patch also changes the flow control of the git
plugin such that submodules which are explicitly set to not be
checked out, are also not fetched but instead ignored completely.

Now that we have Source.validate_cache(), this is a better place to emmit
the ref-not-in-track warning, since it will be emmitted at the earliest
opportunity and not only at Source.stage() or Source.init_workspace().

This also allows us to remove the `self.tracked` local state, and cleanup
some convoluted calling paths, removing some unnecessary parameters from
the usual codepaths and making the plugin overall more readable.

A function for removing paths from a git repo, can also
be used to remove submodules.

 o Test that it is not triggered in show before fetch, because we
   don't know about the unlisted submodules yet

 o Test that it is triggered by a fetch command

 o Test that it is triggered by `show` after having completed a
   fetch command, since now we have the repository and know about
   the unlisted submodule

 o Test all of this under warning or error conditions (parameterized
   for fatal-warnings)

   o Test that it is not triggered in show before fetch, because we
     don't know the submodules yet so we cannot know if they are
     valid or not.

   o Test that it is triggered by a fetch command

   o Test that it is triggered by `show` after having completed a
     fetch command, since now we have the repository and know which
     specified submodules are invalid

   o Test all of this under warning or error conditions (parameterized
     for fatal-warnings)

Implement submodule warnings

See merge request !996

Fix bst source-checkout not working with open workspaces

Closes #807

See merge request !997

This allows specifying whether or not the code believes a None
value is acceptable if explicitly expressed to be None in the YAML.

A previous patch 3ba544b8 changed
the behavior to accept None for all values across the board, along
with allowing explicitly setting the `default_value` to `None` which
caused the code to be much more readable (this was the main motivation
of the patch, but it had the side effect of allowing None for everything).

In the majority of cases we load YAML however, it either has a value or
it is not specified in the YAML, and None is hardly ever acceptable
to be explicitly specified (it may be in the case you want to override
something with nothing in the YAML, but it is the edge case).

This had the side effect of causing unexpected crashes where the
YAML specifies an empty dictionary for instance.

Instead of forcing the caller to handle a possible None value, give
the choice to the caller if they really want to accept a None value,
and raise the LoadError otherwise.

This fixes issue #803, which is a crash due to receival of an
unexpected None value through _yaml.node_get()

Allow plugins to conveniently leverage the new `allow_none` parameter,
and have Plugin.node_get_member() raise a LoadError in the usual
case where None is not an acceptable value to be explicitly set in
the user provided YAML.

This adds a regression test for issue #803

Only optionally allow None values in user provided YAML

Closes #803

See merge request !999