Provide abstract base class for a string object

[awvwgk]

This patch implements an abstract base class (ABC) for an extendible string class (not to be confused with the non-extendible string type). The implementation also shows the full insanity of object oriented string handling in Fortran required to just support the intrinsic functionality and sheds some light on the current state of compilers implementing class inheritance.

Goals of this PR

• provide full compatibility with the functional string_type
• provide overloaded interfaces in the base class to define all character intrinsic functions for both character scalars and functional strings
• add preliminary specs on the public API of the abstract base class
• add developer API documentation for all available type bound procedures
• add tests to check a minimal implementation of a string class

Design strategy

• provide an ABC rather than an actual class to handle extendible string objects
• rely on the string_type as return value rather than returning polymorphic string objects
• stdlib_string_class defines and exports overloaded interfaces for the ABC, which should be reexported in implementations to provide intrinsic functionality (still requires explicit import)
• operators and UDDTIO are type-bound rather than overloaded interfaces (easier to import)
• string_class can be created by assignment from character values, string types or string objects

Additional resources

I prepared the stdlib_string_class module in awvwgk/stdlib_string as fpm project. The specs are available at https://awvwgk.github.io/stdlib_string. The projects also includes a version of ftlString and StringiFor based on the string_class proposed here.

[milancurcic]

Does this add functionality relative to the string_type or is it just an API difference?

[awvwgk]

As with the string_type patch, I'm trying to not add any functionality with this patch yet, but provide a scaffold with the already existing functionality to build upon later. The main difference between string_type and types inheriting from string_class are that the latter are extendible. Also, due to the fact that they are class polymorphic, function pointers are resolved at runtime rather than at compile time.

[milancurcic]

Okay, thanks. I think it warrants a broader discussion then. Should stdlib offer:

1. Only the string type
2. Only the abstract string class
3. Both
4. Something else

My current opinion is that we should aim to minimize overlapping functionality. So, is a string_class needed? It seems to me the answer is yes only if you want to extend it, and it's not clear that it would be strongly desired feature. But if it is, then we should ask, should string_class replace string_type or be added to it. Having both is of course an option, but I think it needs to be justified, i.e. there are clear and non-overlapping use cases for both.

[awvwgk]

Yes I would be happy to discuss this in more detail. Parts of the issues regarding functional vs object-oriented string types were discussed in #69, but we should start a separate issue regarding this (see #334).

[awvwgk]

I'm going to mark this patch as wontfix, but will leave it around for now. If anyone is interested in continuing it, let me know or just feel free to adopt it for your project.

[awvwgk]

Since I'm not planning to continue working on this, I'm going to close this PR.

This patch can be resurrected from d3752b0 if needed.