Esql field attribute builder

[not-napoleon]

FieldAttribute had seven constructors. This PR removes three of them, and replaces them with a more readable builder pattern.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[nik9000]

Spelling.

Maybe should just be FieldAttribute.builder() or new FieldAttribute.Builder()?

[idegtiarenko]

There are several cases when the builder is used like here: Builder(...).build() without extra chain calls.
I wonder if it is possible to still keep a constructor with such signature? This will reduce amount of objects created in prod code (not sure if escape analysis proactively eliminates them).

I also wonder if we could achieve similar level of simplification if we:

• remove constructors with fewer usages ans supply extra arguments explicitly:
  

  elasticsearch/x-pack/plugin/esql-core/src/main/java/org/elasticsearch/xpack/esql/core/expression/FieldAttribute.java

  Lines 51 to 53 in e95397c

  	public FieldAttribute(Source source, @Nullable String parentName, String name, EsField field) {
  	this(source, parentName, name, field, Nullability.TRUE, null, false);
  	}

  
  has 4 usages
  

  elasticsearch/x-pack/plugin/esql-core/src/main/java/org/elasticsearch/xpack/esql/core/expression/FieldAttribute.java

  Lines 55 to 57 in e95397c

  	public FieldAttribute(Source source, @Nullable String parentName, String name, EsField field, boolean synthetic) {
  	this(source, parentName, name, field, Nullability.TRUE, null, synthetic);
  	}

  
  has only 1.

• Consider scope
  

  elasticsearch/x-pack/plugin/esql-core/src/main/java/org/elasticsearch/xpack/esql/core/expression/FieldAttribute.java

  Lines 47 to 49 in e95397c

  	public FieldAttribute(Source source, String name, EsField field) {
  	this(source, null, name, field);
  	}

  
  this has a lot of usages and all but 4 are test ones. May be it is worth having a test utility?

[not-napoleon]

remove constructors with fewer usages ans supply extra arguments explicitly

I was under the impression that FieldAttribute, being a sub-class of Node was meant to be immutable. I'm not opposed to adding some setters on it for these optional fields, but if immutability is important for these classes, that seems like a risky plan

[nik9000]

I'd keep it immutable. We certainly could just hard call the ctor every time if we're worried about the allocations, but I haven't been too worried about them in the past.

[idegtiarenko]

remove constructors with fewer usages and supply extra arguments explicitly

To be precise, supply default argument explicitly via constructor prior constructor was delegating to

[not-napoleon]

I wrote up what I think you're asking for in #127920. Personally, I like the builder better, but I'm open to feedback.