Fix pick_peer case clause failure

In the case of {call_mutates_state, true} configuration on the service
in question, any peer selection that failed to select a peer resulted in
a case clause failure in diameter_service:pick_peer/5, when the call to
the service process returned false. This was noticed in the case of a
peer failover in which an alternate peer wasn't available.

The explicit matching is intentional, to match exactly what's expected.
Fix unicode path failure in diameter_make:codec/2

A dictionary path containing a unicode codepoint > 255 caused the
function to fail when iolist_to_binary/1 was applied to the path.
Adapt dictionary compilation to new default encoding

The problem is that the change in default encoding to utf8 in 17.0, in
commit 00e42967, changes the behaviour of erl_parse:abstract/1, which is
used by the dictionary compiler to turn terms into abstract code. In
particular, it transforms the orddict representation of a parsed
dictionary to contruct the return value of a dictionary module's dict/0
function. This orddict contains various lists, one of which is a list of
tuples of the form

  {Name, Code, [VendorId], [Avp]}

where Name is an ASCII string and VendorId is a non-negative integer.

Using erl_parse:abstract/2 instead allows a string encoding to be
specified but regardless of what encoding is used, the result of
transforming our tuple might not be what we really want, which is for
Name to always be represented as a string form and [VendorId] to always
be represented as a cons form: the [VendorId] will always end up as a
string form if the integers are small enough. The only way around this
is to transform the tuple bit by bit, but modifying the code to do this
is quite a lot of work, for not much gain: it would be nice to produce
more readable output but nothing stops working without it.

This commit restores the pre-17.0 conversion by explicilty specifying
latin1 as the string encoding to erl_parse:abstract/2. The utf8 encoding
broke the compilation of some dictionares since unicode strings aren't
expected when writing the generated code to file.

Note that the latin1 encoding does reasonably well in practice, although
it mangles the Ericsson Vendor Id list [193] into a "LATIN CAPITAL
LETTER A WITH ACUTE". The utf8 encoding does worse, mangling the 3GPP
Vendor Id 10415 into "DESERET CAPITAL LETTER CHEE". An ascii encoding
would do better than latin1 but doesn't yet exist. (Encoding isn't
really what the option is. It's a string predicate: if the predicate is
true then represent as a string form, otherwise a cons form.)
Ensure generated modules are properly included in the Emakefile
Add support for testing the LLVM backend too
Use fun encoding to erl_parse:abstract/2

This is an encoding that didn't exist at the time of the previous
commit, but which was added in commit 83b6daef. Use it to restrict
stringification to lists containing printable ascii.
inets: Avoid Windows XP port problems
inets: Avoid timing issus in test case code
Document the asn1_OPENTYPE wrapper
Fix an ampersand
Shorten the Introduction section, keeping only the essential details

We can assume that anyone that reads the documentation for the Asn1
documentation already knows about ASN.1, so we don't need three
paragraphs of introductory. Keep one short paragraph explaining
what ASN.1 is in case a reader unfamiliar with ASN.1 stumbles upon
the manual.

While we are at it, reformat the paragraphs in Introduction to
shorter lines that don't wrap.
Correct and modernize the "A First Example" section

Replace "IMPLICIT TAGS" with "AUTOMATIC TAGS" since AUTOMATIC TAGS
is recommended for all new ASN.1 specifications.
Remove all uses of the deprecated asn1{ct,rt}:{en,de}code/2 functions
Correct the PrimStrings example

The decode functions now return a binary, not an iolist, so we must
both change the output and remove the call to list_to_binary when
decoding.
Correct the UTF8String description and example
Correct and modernize the examples for DEFAULT

It turns out that the current BER back-end can recognize complex
DEFAULT values, so I had to commit up with a more elaborate
example to show a difference between the BER and DER back-ends.
Don't waste words describing the SET type

Since the SET type is used exactly the same way as the SEQUENCE
type in Erlang, we can simply say so and note that decoding will
be less efficient for the BER and DER encoding rules.
Bring information about tags up to date

Since 1994 when the AUTOMATIC TAGS was introduced, ASN.1 users
no long need to worry about tagging, and the following sentence
no longer makes any sense:

  It is essential for all users of ASN.1 to
  understand all the details about tags.

Therefore, remove the entire existing section of tags, and replace
it with a shorter section explaining why we no longer need to know
about tags. Remove all tags from the examples.
Remove the section about encoding rules

The section about encoding rules serves no useful purpose. Most users
already know which encoding rule to use for their specifications.  The
few users that have their own specification and need to decide on
which encoding rule to use will need much more information.
Replace "extend-ability" with "extensibility"

While "extendability" (without the hyphen) is an English word,
"extensibility" is the established term used when talking about
the extensibility of ASN.1 types.