Revise general explanation on type casting

[jaehyun1ee]

Following the discussion made at #1351, this PR revises the general explanation on type casting given in section 8.11. Casts* to the following:

;; Before

P4 provides a limited set of casts between types. A cast is written
`(t) e`, where `t` is a type and `e` is an expression. Casts are only
permitted on base types and derived types introduced by `typedef`, `type`, and `enum`.
While this design is arguably more onerous for programmers, it has several benefits:

;; After

P4 provides a limited set of casts between types. A cast is written
`(t) e`, where `t` is a type and `e` is an expression. Casts are only permitted in
cases as defined in section <<sec-explicit-casts>> for explicit casts and
section <<sec-implicit-casts>> for implicit casts. While this design is arguably
more onerous for programmers, it has several benefits:

Rather than stating "Casts are only permitted on base types and derived types introduced by typedef, type, and enum." (which is quite inaccurate), it puts forward references to the following subsections. Because:

• Not all base types can be casted (e.g., void, error, match_kind, and string)
• Derived types, such as struct and header can be casted, e.g., at initialization.

[jafingerhut]

At 2025-Jan-13 vlstill agreed to review in detail. No other LDWG members could think of reasons to object based on our discussion, but they should review and add their comments if they wish.

[vlstill]

I agree with the new wording. For the sake of readability of this area of the spec I suggest some tweaks to the following text.

[vlstill]

maybe this sounds a little better?

Suggested change

	`(t) e`, where `t` is a type and `e` is an expression. Casts are only permitted in
	cases as defined in section <<sec-explicit-casts>> for explicit casts and
	`(t) e`, where `t` is a type and `e` is an expression. Casts are only permitted in
	cases defined in section <<sec-explicit-casts>> for explicit casts and

[vlstill]

I think the last sentence makes little less sense with the forward references. I suggest something like this:

Suggested change

	section <<sec-implicit-casts>> for implicit casts. While this design is arguably
	more onerous for programmers, it has several benefits:
	section <<sec-implicit-casts>> for implicit casts. Main goals of this design are:

and possibly add

• It limits implicit casts to the bare minimum.

[vlstill]

I'd say the last one should be separate. and probably not a bulletpoint.

Suggested change

	* It reduces the number of cases that have to be considered in the P4
	specification. Some targets may not support all casts.
	* It reduces the number of cases that have to be considered in the P4
	specification.
	Note: some targets may not support all casts.