Be consistent about including names in framework-provided messages

[dougbu]

Resources for framework-provided messages are inconsistent, especially around whether they include names and, when names are displayed, what is shown. Some of these cases may be usability regressions.

Should decide general rules for framework-provided messages and then apply to existing messages. E..g. perhaps "always show the property name" -- not much reason to be vague about the problematic property once we've decided to inform the user of a problem.

---

A few examples:

• ModelStateDictionary adds Resources.ModelError_InvalidValue_GenericMessage and Resources.ModelError_InvalidValue_MessageWithModelValue messages when a FormatException occurs. This message includes the full key (property / collection path) e.g. "model.Customer.Name". For consistency with MVC 5 and usability, should instead use the DisplayName of the problematic property and fall back to the property name.
• MutableObjectModelBinder adds Resources.ModelBinding_MissingBindRequiredMember messages when no data is provided for a [BindRequired] property. This message includes the property name, never the DisplayName.
• SimpleTypeModelBinder adds Resources.ModelBinding_NullValueNotValid messages when no data is provided for a non-Nullable value type property or collection entry. This message includes the value but no property name or path.
• KeyValuePairModelBinder adds Resources.FormatKeyValuePair_BothKeyAndValueMustBePresent messages when only one of the key or value are bound. This message does not include information about which property value was missing.

---

A few derivative cases might inform our decisions here:

• Model may include a List<int> or similar opportunity for errors where DisplayName is never available and no property name is meaningful.
  • The KeyValuePairModelBinder case is similar, especially when binding a dictionary.
• Model may include large numbers of properties with Id, Name, and other repeated names. Must users add DisplayName everywhere to distinguish these properties? How would that requirement be discovered without testing the site and hitting invalid cases?
• Errors are shown in both validation summaries and per-field validation messages. For the second, additional context may seem redundant.

[danroth27]

We decide to fix #3227.