Improve Relaxed Decode of table attributes in MIB Upload Next responses

Currently Table Attributes found in a MIB upload next response results in a decode error as Table Attributes should not be present.  To improve interoperability, relaxed decoding could help onboard new ONUs to the OpenONU and also help out should an firmware upgrade of supported ONUs result in an error.

The desired behavior should be to successfully return both the OMCI header layer and the MIB Upload Next response layer (not NIL). An additional 'DecodeError' layer, similar to what is done for the relaxed attribute decode should be provided.

In the successfully decoded MIB Upload Next response layer, the attribute mask will only contain the bitmask of successfully decoded attributes.  Attributes are decoded from MSB to LSB (left to right).  Note that if the first attribute that is attempted to be decoded is a table attribute, this mask will be 0x0000.

When the first table attribute is encountered, the custom DecodeError layer will contain:

• an error message string with a message useful for logging purposes
• the 'failed' attribute mask of all remaining attributes in the original message
• a field with the byte array of the remaining data in this message

The failed attribute mask can either be ignored, or used in later processing to get the actual attributes via individual GET and GET-NEXT request/responses if the OpenONU so desires.

For baseline format messages, the remaining data will be from the start of where the table was suppose to start at and will end at the octet just before the Length OMCI trailer field. So extra data may be returned in some cases.

For extended format messages, the data will also start at the table location in the data and will end at the embedded ME in the message.  Extended MIB Upload Next response messages have a length field to indicate where the 'next' ME in the response starts.