Use ABSTRACT keyword to indicate an abstract deferred type, in order to resolve issues with the distinction of deferred-type vs deferred-class

[aury6623]

There are inconsistencies with the usage of "deferred type"/<deferred-type> and "deferred class"/<deferred-class>

• generics/J3-Papers/syntax-intro-and-deferred-args.txt

  Lines 112 to 114 in cc42f87

  	A deferred type is a deferred argument that can appear as a
  	<type-spec> within a REQUIREMENT construct, TEMPLATE construct, or
  	STP.

• generics/J3-Papers/syntax-intro-and-deferred-args.txt

  Lines 318 to 319 in cc42f87

  	A <deferred-type> is a deferred type. A <deferred-class> is an
  	abstract derived type.

• generics/J3-Papers/syntax-intro-and-deferred-args.txt

  Lines 437 to 449 in cc42f87

  	Constraint: If any ultimate specification of a deferred argument is a
  	deferred type, then all ultimate specifications of that
  	deferred argument shall be deferred type.
  	Constraint: If any ultimate specification of a deferred argument is a
  	deferred class, then all ultimate specifications of that
  	deferred argument shall be deferred class.
  	If any ultimate specification is deferred type, then that argument is
  	deferred type.
  	If any ultimate specification is deferred class, then that argument is
  	deferred class.

In the third of those 3 snippets, we assume that "deferred type" and "deferred class" are mutually exclusive categories. However, in the first snippet, as well as the section headers in the document, we refer to both things together as "deferred type". We also say "can appear in a <type-spec>" in the first snippet, which is not true of deferred class. We also group them in the BNF, such as "<deferred-type-declaration-stmt>" which is either TYPE, DEFERRED or CLASS, DEFERRED. We need to be more precise with the terms here.

In the existing standard, "class" is not a term used to describe a type, and it's not really even a word used to describe a data object. I think the closest it gets to that is the "CLASS IS" syntax in a <type-guard-stmt>. CLASS is only a type specifier which declares polymorphic data objects. I think our problem might be the use of the word "class" at all to describe the concept we want; when I see CLASS in Fortran, I think "declaration of an object", not "definition of a type".

The TYPE, DEFERRED :: type-name declaration is supposed to be analogous to the TYPE :: type-name construct, right? So I think it would be more clear to use TYPE, ABSTRACT, DEFERRED :: type-name as the declaration, analogous to TYPE, ABSTRACT :: type-name.

With that notion, this PR is my proposal to address the inconsistencies between <deferred-type> and <deferred-class>.

If the TYPE, ABSTRACT, DEFERRED :: type-name syntax is not preferred, we could still revert back to the CLASS, DEFERRED :: type-name syntax and keep everything else in this edit the same, except the normative text would change to:

If [[ABSTRACT appears -> CLASS is used]] in <deferred-type-declaration-stmt>, the declared
deferred types act as if they were abstract extensible derived types.
Otherwise, they act as if they were non-extensible types.

[aury6623]

I put this back because I realized why it's necessary for this edit.

The "except when used as an <instantiation-arg>" is not directly relevant to this edit, but is important, so I gave it its own PR: #127

But indicating that <deferred-type> must not be abstract is important because it solves the issue @everythingfunctional was talking about: it prevents you from using an abstract deferred-type in a TYPE IS statement.

[aury6623]

Note that "extensible type" here is a generalization of "abstract type" and allows us to expand to something like TYPE, EXTENSIBLE :: T in the future without needing to change this constraint. Abstract should imply extensible.

[everythingfunctional]

I'm coming around to @aury6623 's proposal here. I think we should go ahead and include extensible while we're at it. I think I've worked out exactly what is needed for all this, so I'll have something submitted later today.

[everythingfunctional]

Addressed by #131