Obscure value mocking

[RazzM13]

The current way of mocking values that are required throughout the validation process does not provide users with any sort of information that mocking is taking place or what values are being guessed and used in the validation process thus, potentially inducing novice users to the fallacy that the validation for the affected items is not up to par, unless otherwise hinted via the README or the command-line usage prompt.

Furthermore, there are incosistencies in the way mock values are being generated / used and no way of detecting conflicting values that refer to the same entity; with the introduction of 4ae1383 one such irregularity has arrisen for resource attributes, which previously had their values generated during assignResourcesOutputs, are now being overriden during a call to fnGetAtt to satisfy list-type properties / intrinsic requirements.

Even though I am an advocate for ItJustWorks (TM), imperfections such as these can have a negative impact on a project's user experience and codebase maintenance in the long term therefore, to alleviate the aforementioned, I would like to suggest that the following be implemented:

• A register of mocked attribute values that exhibits a dual role of notifying a user about the mocked values that are in play as well as keeping track of potential value conflicts for the same attribute that may arrise during runtime and, notifying if such a conflict occurs;
• A centralised way of generating mocked values based on value type and/or attribute type;
• Contextual resolution for mocked values that should be based on the need of a specific value during validation in the template's current position as well as within an intrinsic expression or a chain of intrinsic expressions.