Make each attribute its own class

[Scott-Guest]

I've spent quite a bit of time trying to get #3993 working, and have yet to find a solution which simultaneously:

• Supports type safe lookup and insertion, accounting for forbidden / optional / required values of any possible type
• Allows us to maintain a single overloaded add function even in the presence of type erasure
• Doesn't cause falsely reported error messages in the Java code

Additionally, I've noticed a few pain-points with the current set up:

• We conflate two separate concepts
  • key(value) string pairs actually used as attributes in K or KORE source code
  • arbitrary data attached to syntax for use internally in the frontend, e.g., the Sort or Production attributes
• Attribute values are often structured data but stored as strings, meaning
  • The value parsing logic is decoupled from the attribute definition
  • The value has to be re-parsed every time it's read and re-stringified every time it's written (else we run into issues like #3960)
• Att.scala makes somewhat heavy usage of Scala-specific features, even though we plan to eventually deprecate Scala in the codebase

One possible solely-Java solution would be to:

• Make Att store a heterogenous Set of classes rather than a Map of key-value pairs.
  • Internally, this would probably be a Map<Class<?>, Object> mapping Foo.class to at most one instance of Foo for fast lookup, but the external interface would be Set-like.
• Arbitrary data can just be added as an instance of any class.
• Actual attributes MyAtt which should be considered for parsing in the frontend or emitting to KORE can implement an Attribute interface:

  class MyAtt implements Attribute {
  static public String key();
  public String value();
  static public Either<KEMException, MyAtt> fromValue(Optional<String> val);
  public EnumSet<Syntax> allowedSyntax(); // Empty if not visible to users
  public boolean shouldEmitToKORE();
  }

  Type-safe value creation/lookup is then handled by each attribute's constructors/methods rather than the Att.scala class.

[Baltoli]

Don't have a monolithic PR; do smaller changes by keeping both implementations for a period of time.

[Scott-Guest]

Putting this on the backlog. It's low-priority and more work than we have bandwidth for at the moment.