Polymorphic array and byte string literls [T; N]/[T]

[petrochenkov]

Array literals ([1, 2, 3]) and byte string literals (b"abcd") have their length as a part of their type, because sometimes it's crucial to know the length at compile time.
This approach have a couple of downsides:

• First, every time these literals interact with generics it is an invitation to code bloat, because literals with different lengths generate different instantiations of generics. (On the other hand, this code bloat has a chance to be counterbalanced by better const propagation in specialized code and further optimizations.)
• Second, it leads to inconveniences like Functions in std should accept &[T; N] whenever they accept &[T] rust#21725, i.e. some extra traits have to be implemented for fixed arrays of different sizes in order for array literals to be usable in some contexts.

In practice, most of the time the length is needed only at runtime and can be erased from the type of an array or byte string literal.
So, my suggestion is to make array and byte string literals polymorphic, similarly to integer literals. They will have dynamically sized type by default and statically sized type when necessary (this part requires better specification and implementation experience).
(String literals could be made polymorphic too, when something like FixedString<N> is implementable.)

Currently array and byte string patterns behave somewhat similarly - they adapt to the type of the match discriminant and denote either sized or unsized arrays.

[steveklabnik]

I think this is effectively a dup of #1038

[petrochenkov]

The issues are orthogonal. That one doesn't resolve this one and otherwise, and both can be implemented independently.