support @GlobalTransactional and @GlobalLock in parent class and interface

[whaon]

• I have read the CONTRIBUTING.md guidelines.
• I have registered the PR changes.

Ⅰ. Describe what this PR did

support @GlobalTransactional and @GlobalLock in parent class and interface

Ⅱ. Does this pull request fix one issue?

fixes #7793

Ⅲ. Why don't you add test cases (unit test/integration test)?

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

[codecov]

Codecov Report

❌ Patch coverage is 75.38462% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.93%. Comparing base (9998778) to head (b8cd3cf).
⚠️ Report is 9 commits behind head on 2.x.

Files with missing lines	Patch %	Lines
...a/org/apache/seata/common/util/ReflectionUtil.java	71.42%	8 Missing and 8 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                2.x    #7794      +/-   ##
============================================
+ Coverage     69.96%   70.93%   +0.97%     
- Complexity      992      993       +1     
============================================
  Files          1322     1322              
  Lines         50177    50237      +60     
  Branches       5932     5947      +15     
============================================
+ Hits          35104    35634     +530     
+ Misses        12143    11666     -477     
- Partials       2930     2937       +7     

Files with missing lines	Coverage Δ
...handler/GlobalTransactionalInterceptorHandler.java	41.90% <100.00%> (+1.41%)	⬆️
...r/parser/GlobalTransactionalInterceptorParser.java	63.15% <100.00%> (-1.71%)	⬇️
...a/org/apache/seata/common/util/ReflectionUtil.java	73.04% <71.42%> (-0.46%)	⬇️

... and 30 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[funky-eyes]

I believe method-level annotation data should take precedence. Only if a method does not have that annotation should we check the corresponding method in the superclass. This ensures that if the same annotation appears with different configured values, the value on the method is the one that ultimately applies.

[whaon]

you are right! the invoker will check the actual class first just as you wish
code is here:

    private <A extends Annotation> A findAnnotation(Method method, Class<?> targetClass, Class<A> annotationClass) {
        A anno = getAnnotation(method, targetClass, annotationClass);
        if (anno == null) {
            anno = ReflectionUtil.findAnnotationInHierarchy(
                    targetClass, method.getName(), method.getParameterTypes(), annotationClass);
        }
        return anno;
    }

[funky-eyes]

Should we attempt to read the annotation from the superclass instead of only checking the method itself?

[whaon]

update, pls have a check