Spec clarifications

[vvenz1n]

1. clarify branching support in nightly spec
2. note node table horizontal scrolling
3. clarify duplicate inline definitions
4. clarify component reference scope
5. exclude null from string conversion rule
6. clarify default value compatibility
7. clarify reference validity rules
8. clarify node parameter constraints
9. clarify map node IO rules

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: vvenz1n

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[cesarebernardis]

This is a new limitation and a breaking change, we kept the conversion of any type to string for simplicity. I don't think we should add this.

[vvenz1n]

json-schema says that null can have exactly one value, and it’s null

https://json-schema.org/understanding-json-schema/reference/null#null

Given that strictness, I think it’s better to not allow converting it.

E.g. anyOf{string, null}  -> string , should not work IMO.

The target here wants a string, it doesn’t expect (or know) what to do with null

“null”  means explicitly “no value” or “absence of value”, so converting it into a value seems not correct to me.

[oracle-nish]

We might have several instances in an executor implementation where we would need anyOf{string, null} -> string.

1st example that comes to mind is:
An AgentSpec has a ToolNode / LLMNode accepts an output property which is an anyOf{string, null} with a default value of "null". Here, we may have an outgoing dataflow connection to an BranchingNode which needs to make a control flow decision based on the null value. Since we currently allow only string representations of mappings, executors might need to allow the anyOf{string, null} -> string conversion to happen to do mapping string compare check.

2nd (rather simpler) example: We may simply have a requirement to display a stringified "null" value to the user for specific cases where either a ToolNode/LLMNode/AgentNode returns null, which would require the data flow connection from anyOf{string, null} to string to be valid.

Hence, I do agree with @cesarebernardis that this rule can be made more lenient.