Add Table Gen support to refactor of collectSYCLAttributes()

[smanna12]

I am starting to think more and more that it's past time to table generate this logic rather than continuing to struggle to maintain these lists manually. Do I understand correctly that we really have one collection need with three (maybe four) modes: never propagate, always propagate, only propagate when directly called (possibly with a diagnostic), but the mode may differ based on the language options? If so, we could perhaps try to design a tablegen feature to do this. e.g., something along the lines of

let SYCLKernelPropagationBehavior = [SYCLKernelPropMode<SYCL2020, NeverPropagate>, // SYCL 2020 behavior
                                     SYCLKernelPropMode<SYCL2017, AlwaysPropagate>] // SYCL 2017 behavior

(Where SYCL2020 and SYCL2017 are new LangOpt definitions we add to Attr.td and the *Propagate are enumerations we define.)

Thinking out loud: we'd generate a function named static bool isAttributeCollected(const Attr *A, const LanguageOptions &LangOpts, bool IsDirectlyCalled); that returns whether an attribute should be collected or not. We'd have to collect all of the SYCLKernelPropagationBehavior objects in Attr.td so that we could group the language mode checks together in the resulting generated file. What we'd generate would effectively look like:

if (LangOpts.getSYCLVersion() == SYCL_2017) {
  if (isa<large generated list of attributes here>(A) && IsDirectlyCalled) // SYCL 2017, propagate if directly called
    return true;
  if (isa<large generated list of attributes here>(A)) // SYCL 2017, always propagate
    return true;
}
if (LangOpts.getSYCLVersion() >= SYCL_2020) {
  if (isa<large generated list of attributes here>(A) && IsDirectlyCalled) // SYCL 2020, propagate if directly called
    return true;
  if (isa<large generated list of attributes here>(A)) // SYCL 2020, always propagate
    return true;
}
return false;

where each of the generated lists of attributes in the isa<> checks are based off the propagation enumeration from Attr.td.

If we want to include diagnostics in the logic, I think we'd return an enumeration rather than a boolean and let the caller figure out what diagnostic to emit, whether to drop the attribute, etc. But given that we only have one of those, we may just want to handle that case specially.

Then, collectSYCLAttributes() will defer most of the logic to the generated isAttributeCollected(), but can still house any custom logic we need (like for diagnostics).

WDYT? (Note, there may be tweaks needed to the idea -- this was designed somewhat off-the-cuff, so if you have a better idea of how to express this in Attr.td, we should definitely explore it.)

Originally posted by @AaronBallman in #3836 (comment)