Fix corruption of internal encoding string

[Bug #20598]

Just like [Bug #20595], Encoding#name_list and Encoding#aliases can have
their strings corrupted when Encoding.default_internal is set to nil.

Co-authored-by: Matthew Valentine-House <matt@eightbitraptor.com>

Fix corruption of encoding name string

[Bug #20595]

enc_set_default_encoding will free the C string if the encoding is nil,
but the C string can be used by the encoding name string. This will cause
the encoding name string to be corrupted.

Consider the following code:

    Encoding.default_internal = Encoding::ASCII_8BIT
    names = Encoding.default_internal.names
    p names
    Encoding.default_internal = nil
    p names

It outputs:

    ["ASCII-8BIT", "BINARY", "internal"]
    ["ASCII-8BIT", "BINARY", "\x00\x00\x00\x00\x00\x00\x00\x00"]

Co-authored-by: Matthew Valentine-House <matt@eightbitraptor.com>

Fix memory leak in setting encodings

	There is a memory leak in Encoding.default_external= and
	Encoding.default_internal= because the duplicated name is not freed
	when overwriting.

	    10.times do
	      1_000_000.times do
	        Encoding.default_internal = nil
	      end

	      puts `ps -o rss= -p #{$$}`
	    end

	Before:

	     25664
	     41504
	     57360
	     73232
	     89168
	    105056
	    120944
	    136816
	    152720
	    168576

	After:

	    9648
	    9648
	    9648
	    9680
	    9680
	    9680
	    9680
	    9680
	    9680
	    9680

when the RUBY_FREE_ON_SHUTDOWN environment variable is set, manually free memory at shutdown.

Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Peter Zhu <peter@peterzhu.ca>

It doesn't even have a mark function.
It's only about a hundred objects, but not reason
to scan them every time.

now `enc_table->list` is not a pointer.

This reduces global lock acquiring for reading.
https://bugs.ruby-lang.org/issues/18949

* And simplify callers of get_actual_encoding().
* See [Feature #18949].
* See https://github.com/ruby/ruby/pull/6322#issuecomment-1242758474

* See [Feature #18949].