Most string-based HTML helpers use unprefixed `ViewDataDictionary` entries if called from templates

[dougbu]

The string-based helpers not mentioned in #1485 (@Html.TextArea() etc.) also do not behave as expected in template views. But this problem occurs only if an entry exists in the ViewDataDictionary matching the (un-prefixed) expression name. So unexpected values will be used in the generated HTML -- luckily, in a somewhat narrow case.

E.g. action contains

ViewData["Age"] = 39;
return View(new User()
{
  Age = 26,
  Dependent = new User()
  {
    Age = 13,
  },
});

Index.cshtml contains

@Html.DisplayFor(model => model.Dependent, templateName: "Dependent")

DisplayTemplates/Dependent.cshtml contains:

<td>
    @Html.Label(expression: "Age", labelText: null, htmlAttributes: new { @class = "control-label", })
</td>
<td>
    '@Html.Value(name: "Age")'
</td>

Result is:

Expect to see "13" displayed between the quotes.

[dougbu]

This problem was inherited from MVC 5.2.

Fix would probably require a general change in how we evaluate expressions that may be in ViewDataDictionary or its Model when !string.IsNullOrEmpty(ViewData.TemplateInfo.HtmlFieldPrefix). In that case, the full name of a dictionary entry and its name relative to the current Model are different. Should pass both names to ViewDataEvaluator.Eval(), allowing that helper to evaluate the full name against ViewDataDictionary entries. Then, if that fails, the helper would evaluate the relative name against ViewDataDictionary.Model. This preserves the current precedence of ViewDataDictionary entries over properties of ViewDataDictionary.Model.

The current code mixes ViewDataDictionary lookups with evaluating properties in the Model. This works fine in many cases, but not in this specific situation.

Fix isn't particularly risky because we have good but still-improving (see @pranavkm's work on #453) unit tests touching on ViewDataEvaluator.Eval(), Also have functional tests and samples demonstrating the behaviour of various HTML helpers.