Deprecate `emphclass`

[bertfrees]

The emphclass opcode doesn't really have a purpose anymore (or never really had).

Emphasis classes could be added implicitly whenever a new class is used in a emphletter/begemphword/endemphword/begemph/endemph/begemphphrase/endemphphrase/lenemphphrase rule.

I think we added the opcode to allow table authors to control the order of the classes in the typebuf argument. But it doesn't make sense because applications should never hard code the typebuf bits. This is only acceptable for bold, italic and underline because these predate lou_getEmphClasses.

For backwards compatibility we currently require that bold, italic and underline are the 3 classes that are defined first. But we don't need the emphclass opcode for that. This can be done implicitly.

[jrbowden]

Hi, I'm a bit concerned that some systems will need to guarantee the order of bits in the emphasis. UEB for example defines several additional classes of emphasis apart from italic, underline and bold. US defines different ones. Do we guarantee that the bit order will be the same order as an emphasis class is defined in the table?

[bertfrees]

The bit order could in practice still be controlled though the order of emphletter/begemphword/endemphword/begemph/endemph/begemphphrase/endemphphrase/lenemphphrase rules. So if the author of a table really wants the bits to stay the same, he can.

However I wouldn't guarantee it for all tables. The bit order has never been part of the contract of a table (except for bold, italic and underline). If some systems depend on a specific order, they are not using the API correctly.