Revert annotation handling mechanism to not use the original config map or secret resource name location

[isutton]

After #407 an undocumented behavior regarding annotations meant to extract config map and secret values has been unwillingly changed and needs to be reverted.

The annotations handling mechanism after #407 extracts the whole contents of the config map or secret to the same path where the config map or secret name has been stored (resulting in, for example, .status.secretName.password if .data.password is present in the associated resource) to workaround situations where two services might have a password field within different paths and might get shadowed, whereas before #407 it used to extract the contents to the root of the resulting object (for example, .password), imposing no issue whatsoever because there were only one service being declared in the binding.

For reference, see #475 (comment).

[sbose78]

@isutton would you want to pick this up?