TOML interface and nilability

[ben-albrecht]

With the recent nilability changes in the language, the TOML package has received various organic updates to keep it working and passing testing. However, these updates have led to an inconsistency in the TOML interface: Some methods expect a Toml? while other expect a non-nilable Toml, and similarly for returns.

This inconsistency results in some confusing and ugly-looking user code when using the TOML module (e.g. Mason source code for modifying Mason.toml).

One solution could be to always use non-nilable Toml types in the TOML interface. Rather than relying on Toml[<index>] == nil to see if a field exists, users could rely more on Toml.pathExists(<index>) to confirm this.

[ben-albrecht]

This came up in discussion with @benharsh during development of https://github.com/chapel-lang/chapel/pull/14985

[ankushbhardwxj]

users could rely more on Toml.pathExists() to confirm this

@ben-albrecht I agree, this definitly improves code readability