[AIE] Add a SubtargetFeature capability set for aie2p

[atassis]

Motivation

The AIE backend has no real capability mechanism today. The ProcessorModel
subtarget feature lists are empty and target selection is by CPU name, so code
that needs to know what a part supports falls back to #if __AIEARCH__ == 21
style gating (for example in clang/lib/Headers/aiebase_typedefs.h). That
treats capability as a level, but the revisions are not nested: aie2p has
native bfp16, while aie2ps drops bfp16 for MX and adds native fp8. Capability
is a set, not a point on a line.

This change adds real SubtargetFeature flags so code can query a capability
(for example ST.hasBFP16() in the backend, or #if __AIE_HAS_BFP16__ in a
kernel) instead of hard-coding an arch number. It mirrors how AMDGPU already
models capability as a feature set rather than a level. It is the smallest
self-contained step in that direction and does not change codegen for existing
targets.

I wrote up the fuller reasoning, including how this lines up with AMD's own GPU
stack, here: https://atassis.ru/writing/amd-contract-first-e99255/
That is an outside suggestion and not an AMD position; this PR is just the
first concrete slice.

What changed

Backend:

• Add a new AIEFeatures.td with two real SubtargetFeatures: FeatureBFP16
  (native block-floating-point multiply-accumulate) and FeatureAcc2048
  (2048-bit accumulator register file). It is a set, not a level.
• Include it from AIE2P.td and add the two features to the aie2p
  ProcessorModel feature list, which was previously empty. aie2 and aie2ps
  are left as they were, so aie2ps deliberately does not gain bfp16. That is
  what shows the set is not nested.
• TableGen now generates hasBFP16() and hasAcc2048() on the aie2p
  subtarget. I expose them through the standard GET_SUBTARGETINFO_MACRO
  expansion in AIE2PSubtarget.h, declaring the generated bits ahead of the
  members that trigger ParseSubtargetFeatures so the default initializer
  cannot clobber a parsed value.

Clang:

• The AIE target defaults bfp16 and acc2048 on for the aie2p triple in
  initFeatureMap, resolves any -target-feature override in
  handleTargetFeatures, and emits __AIE_HAS_BFP16__ / __AIE_HAS_ACC2048__
  from getTargetDefines, the same shape as __AVX__ on X86. hasFeature
  reports the same bits.

What did not change

• No codegen change for any existing target. The features only add queryable
  state; nothing in tree selects on them yet except the new test kernel, which
  selects a path via the capability macro rather than an arch guard.
• The aie2 and aie2ps ProcessorModels are untouched.

Testing

• clang/test/Preprocessor/aie-capability-macros.c: __AIE_HAS_BFP16__ is
  defined for aie2p by default, absent when compiled with -target-feature -bfp16, and absent for aie2ps. So the macro tracks the capability, not the
  target name, and the set is not nested.
• clang/test/CodeGen/aie/aie2p/aie2p-capability-select.cc: a kernel selects
  its multiply-accumulate path with #if __AIE_HAS_BFP16__ and no arch guard.
  It lowers to the native path by default and to the fallback when the feature
  is turned off.