Vague error for equals sign in resolver when creating config from dataclass

[addisonklinke]

Describe the bug
If users create their config from dataclass objects (Hydra structured configs) and accidentally put an equals sign in a resolver string, the error traceback is vague and does not point to the offending key

To Reproduce

from dataclasses import dataclass
import traceback
from omegaconf import DictConfig, OmegaConf
from omegaconf.errors import GrammarParseError


# The root cause is the equals sign in ``default=``
problematic_equals_resolver = '${oc.env:API_KEY, default=abc123}'

# Dataclass configs (produce vague error)
@dataclass
class ConnectConf:
    api_key: str = problematic_equals_resolver

@dataclass
class TasksConf:
    connect: ConnectConf = ConnectConf()

@dataclass
class Conf:
    tasks: TasksConf = TasksConf()

# Plain dict config (produces good error)
dict_conf = {
    'tasks': {
        'connect': {
            'api_key': problematic_equals_resolver}}}

# Checkout the stack traces
try:
    OmegaConf.create(dict_conf)
except GrammarParseError:
    traceback.print_exc()
    print('^^ Good error showing a ``full_key`` value\n\n')
try:
    OmegaConf.create(Conf)
except GrammarParseError:
    traceback.print_exc()
    print('^^ Vague error with an empty ``full_key``\n\n')

Expected behavior
Whether the OmegaConf config is created from a plain dict or dataclasses, the error should have full_key: tasks.connect.api_key

Additional context

• OmegaConf version: 2.1.0.dev24
• Python version: 3.6.13
• Operating system: Ubuntu 18.04

[omry]

Creation errors in dataclasses are not optimal right now. This is something we will try to improve in OmegaConf 2.2.
The issue is not specific to custom resolvers.
We will take a look to see if we can improve it in 2.1 but chances are this this and other similar issues will not be addressed in 2.1.

This is pretty close to #658.

[addisonklinke]

Ah guess this was already on your radar, but maybe this helps writing additional test cases once there's time to address it in 2.2
If not, it's fine to close if the other issue is sufficient

[omry]

We will take a look to see if the usage of custom resolvers here is causing any additional complications.
If not, we can just close it in favor of #658.