Unifying container (struc/enum/union) and function definition syntax

I had this idea initially in #2859, but I think it better to put it in a dedicated issue.

There are 5 types of "containers" in zig: 1: struct, 2: enum, 3: union, 4: error, and 5: file.

Of these, all containers (except files) may be instanced, so the containers have some instance members and some namespace members. Since the current syntax for defining instance members looks very much alike defining parameters in a function, why not make container syntax more like the existing function syntax?

Rationale:

• namespaces work the exact same way for all 5 container types (easier to reason about)
• whatever is specific to the container type is within the left and right parenthesis (the specifics of each container become more decoupled)
• more room for maneuver if changing syntax in the future, e.g access modifiers on fields

// function definition for comparison
const F = fn(..param..){
  // body
}

// the base template for all containers:
const C = genericContainer<optionalParam>(
  // instance members
){
  // namespace members
}

const S = struct(
  x : f32,
  y : f32
){
  const add = fn(self: S, other: S){
    // body
  }
}

// on a single line
const S2 = struct(x: f32, y: f32){}

// need to use angle brackets for the tag type now
const E = enum<tagtype>(
  ON, OFF, DONTCARE
){}

const U = union<tagtype>(
  theint : u32,
  thebool : bool,
){}

const Err = error(
  ParseError, 
  IoError
){}

// Files would then simply be equal to
const F = struct(..no instance members here..){
  // file content goes here..
}

// instantiating a container would be done with normal parenthesis instead of curly braces to 
// emphasise the fact we are dealing with an instance of the struct.
const myInstance = S(.x=1.0, .y=3.4);

One downside is that there will be two (possibly multi-line) scopes for each single container, which creates some visual noise.

[daurnimator]

Files are structs, so you can cross one container type off your list

Files are structs, so you can cross one container type off your list

I think they deserve a mention. That they live on the file system is enough of a difference for me, and files would still be structs given my proposal, it's just that they would never have instance members.