Overzealous bitbake function scope handling results in incorrect parsing

[michalsieron]

I am not sure why oelint-parser tries to handle nested scopes in bitbake functions, but it results in incorrect parsing output.

Example:

foo() {
    echo '}'
    echo
}

results in

Function -- {'IsPython': False, 'IsFakeroot': False, 'FuncName': 'foo', 'FuncNameComplete': 'foo', 'SubItem': '', 'SubItems': [], 'FuncBody': "    echo '", 'FuncBodyStripped': "echo '", 'FuncBodyRaw': "\necho '}'", 'Line': 1, 'Raw': "foo() {\n    echo '}'\n", 'Origin': '/home/msieron/dev/other/oelint-adv/test.bb', 'InFileLine': 1, 'RealRaw': "foo() {\n    echo '}'\n", 'IsFromClass': False, 'OverrideDelimiter': ':', 'IsNewStyleOverrideSyntax': True, 'InlineBlocks': []}

Item -- {'Line': 3, 'Raw': '    echo\n', 'Origin': '/home/msieron/dev/other/oelint-adv/test.bb', 'InFileLine': 3, 'RealRaw': '    echo\n', 'IsFromClass': False, 'OverrideDelimiter': ':', 'IsNewStyleOverrideSyntax': True, 'InlineBlocks': []}

Item -- {'Line': 4, 'Raw': '}\n', 'Origin': '/home/msieron/dev/other/oelint-adv/test.bb', 'InFileLine': 4, 'RealRaw': '}\n', 'IsFromClass': False, 'OverrideDelimiter': ':', 'IsNewStyleOverrideSyntax': True, 'InlineBlocks': []}

which is incorrect and is visible for example when one enables oelint.spaces.linebeginning rule in oelint-adv.

IMO there is no need to handle nested scopes or even support closing bracket that is not the only thing on the line.
Bitbake itself will only close function scope when it encounters sole } in a line (lib/bb/parse/parse_py/BBHandler.py#L187-L195):

    if __infunc__:
        if s == '}':
            __body__.append('')
            ast.handleMethod(statements, fn, lineno, __infunc__[0], __body__, __infunc__[3], __infunc__[4])
            __infunc__ = []
            __body__ = []
        else:
            __body__.append(s)
        return

[priv-kweihmann]

This is a linter and not bitbake itself, so more syntactically borderline wrong input needs to be parsed.
I'm happy to address that with #369, but for now I'll keep it as it is, as I still haven't seen a real world example that actually requires the need to have unbalanced brackets within a block.
Most of the time it's some hacky sed op, that should have been a patch anyway