Group start issue

Title: Group start issue

Proposal from Sunil & Jacques on an issue assigned to us at last call:

---------------------------------------------------------------------------------------------

Issue:

Group "start" status is redundant with sequence number = 0 used for the

first message of a group. Having two starting group markers is redundant and

may lead to inconsistencies.

Proposal summary:

(a)- we keep seq num = 0 as a MUST for the first message of a group. @status="start"

is no longer used, or relied upon.

(b)- we state more explicitly that the absolute max value for sequence number (in 4.2.1.1)

is 18446744073709551615 (XMLschema unsignedlong)

(c)- we state more explicitly that a group must NOT wrap-around seq numbers,

i.e. when the max integer limit is reached, the group automatically closes.

We add this closing case in 5.1 (T6). 

(d)- we remove the @status attribute from the schema, and use instead an attribute named "last",

with values = "false" or "true". Value "false" is the default. When @last="true",

it is the same as previous @status="end". But it is now OK to have the first message

of a group be also the last one, even when using seq numbers.

NOTE 1: removing @status and using @last instead, is less ambiguous now that

there is no reason to use "start" and "continue". In addition, we keep using "status"

with a different meaning: the spec says frequently that a PollRequest is used to get 

the "status" of messages, which is a different thing. This is confusing.

NOTE 2: a conservative alternative to (d) is to keep @status, but allow only two values: "end", "continue" ("continue" meaning "not end").

NOTE 3: Places affected by teh change from @status to @last: 

simpe edits (in many cases, just remove status="start")

except for subsection (4) in 4.2.1.1 (replace 10 lines). Spec areas affected are:

-Example 1

-Example 5

-sec 4.2.1.1: Line 617, Example 6, Table 3, Subsection (4) on Status attribute (line752-762)

-Table 16 (InvalidMessageParameter entry)

-sec 5.1.1, line 1118.

-sec 5.1.2, line 1127.

-Sec 5.1.3, Termination T3, T4.

-Example 10

NOTE 4: (suggested by Jacques) We also state that it is recommended that the 

sender application only uses a "group handle" - and not directly the GroupId - when 

submitting a message for a particular group. 

*In case* group handles are supported, then in case a Sender submits a message that exhausts 

the last sequence number in a group, then the Sender must be able to keep submitting 

messages for the same group handle, without having to worry about the group it used being closed:

The RMP MUST automatically start a new group with same RM profile as the exhausted one,

and transparently associate the group handle with the new group.