feat(session)!: default the session cookie to __Host-session with Secure

[allen0099]

Part of #256 (part 4 of the proposal: cookie defaults). logout(), read-only Session.user and keep= follow in a separate PR, so this one does not close the issue.

Changes

• SessionConfig.cookie_name defaults to "__Host-session" and cookie_https_only to True.
• A cookie browsers would refuse now raises a ValidationError instead of the 0.3.9 UserWarning:
  • a __Host- name without Secure, with a cookie_path other than "/" or with a cookie_domain;
  • a __Secure- name without Secure.
• Because the default name is __Host-session, setting only cookie_https_only=False, cookie_path or cookie_domain also raises. The message:
  • marks the name as (the default);
  • suggests cookie_name='session', cookie_https_only=False for plain HTTP;
  • suggests cookie_name='__Secure-session' for a path or domain, so the Secure flag is kept;
  • links to the docs.
• The SameSite=None warning no longer fires for a prefixed name, which the prefix check already rejects.
• The middleware's 0.3.9 FutureWarning about the cookie defaults is removed.
• Docs, in both languages:
  • SESSION.md: the "Cookie defaults" section, the config reference, and the HTTPS-only section.
  • MIGRATING_0_4.md#session-cookie: the default-name case, and the note that 0.3.9 warned about it only under the middleware.
• Examples: the plain-HTTP examples keep their explicit cookie settings with updated comments; the HTTPS ones drop them.

Tests

• The 0.3.9 notice tests for 0.4.0: explicit login()/logout() that always rotate the session ID, and __Host- cookie by default #256 are replaced by tests of:
  • the new defaults;
  • each rejected combination, checking the requirements and hints in the message;
  • the accepted combinations;
  • an HTTPS round trip with the default cookie (__Host-session=…; path=/; secure, no Domain).
• Mutation checks, each caught:
  • reverting either default;
  • turning the error back into a warning;
  • dropping the SameSite de-duplication.