Update Intro and Provide Clarity of Motivation for OS-A

[adurbin-rivos]

Add in verbiage largely cribbed from platform policy to set goals
and movitation in approach. Articulate the expectation of OS-A.

Not meant for merge. This is to start a discussion.

[darius-bluespec]

Since this is the first attempt to define a RISC-V platform, we are in
a unique position to define both (1) what a platform is, and (2) the
first one (or few) platforms themselves. I think the introduction
needs to provide a clear definition and scope for both (1) and (2).

For example, with respect platforms generally:

A RISC-V Platform is a specification of one or more standard execution
environments (for example, at M, S, and/or U mode). A Platform
references Profiles (ISA extensions), and also defines other necessary
requirements such as peripherals and environment services such that
compatible implementations and executables may be interchangeable.
Each Platform Specification will define a scope to convey the target
applicability of the Platform.

And with respect to the OS-A platform:

The OS-A Platform specifies an S-mode execution environment sufficient
for binary compatibility in booting general purpose rich operating
systems (such as Ubuntu, RedHat Enterprise Linux, or FreeBSD).

I would also hope that the introduction could be more clear about
terminology used.

For example, software and hardware are used in various different,
conflicting ways. I would recommend avoiding the use of those terms
in most or all cases, using alternative or more specific terms
("platform implementation", "application software", "the operating
system", etc.) as appropriate. With respect execution environments, I
would suggesting using "implementation" instead of "hardware" for the
environment provider, and "executable" instead of "software" for the
environment consumer.

There was a suggestion on the mailing list to use RFC 2119
terminology. I think we should either incorporate that, or else be
clear (with definitions) with terms like "should", "recommended", and
"optional". The Profile specification also defines useful terminology
that might be worthwhile to incorporate.

It might also be useful to add discussion (non-normative) text to
convey some of the non-goals of platforms in general and/or of
specific platforms. For example, that the platform specification is
agnostic to implementation technology (simulation, emulation,
trap-and-emulate, traditional "real" hardware). Or, for the OS-A
Platform at least, given that a device tree and/or ACPI is required,
parameters or other details that can be conveyed through such a
mechanism should not be mandated in the Platform itself.

[kumarsankaran]

@adurbin-rivos Agree with your patch suggestions.
@darius-bluespec Agree with your additional comments as well.
@adurbin-rivos Do you want to update your patch with the additional commentary so we can get these changes in and close this issue? I know we are moving some of these to the OS-A SEE spec. So it will be good to get these changes in so we have a baseline when we pick this up later.

[adurbin-rivos]

@kumarsankaran I think the platform stuff is going to split across new Platform and OS-A SEE so I'm not sure it's necessary to merge. We are going to tease these apart anyway. Let's just keep this request around for now for the content in order to seed OS-A SEE. Then we can drop it. Or if you want to land it first, we can. However, we haven't incorporated Darius's commentary yet either. Your call.

[kumarsankaran]

@adurbin-rivos OK fair enough. Let's keep this PR open for now. We can revisit after we complete definition of the OS-A SEE spec and pull this content into OS-A platforms as needed.