4.0: Incosistencies of `public?` for fields and for arguments and its effect on `accept`

There are two things that differ for `public?` option between fields (attributes/relationships/aggregates/calculations) and arguments - meaning and defaults.

Meaning: for fields right now it means "can it be read over public interfaces", for arguments - "can it be written over public interfaces".

Defaults: for fields it defaults to false and they need to opt-in to appear in an interface, while for arguments it is false and they need to opt-out from being public (like in Ash 2).

Those discrepancies also manifest in `accept` list creating all attribute arguments as public even if an attribute itself is not.

So it ends up being that:
Writing a private argument - not ok.
Writing a private attribute - ok.

I am of opinion that it is better to consolidate meanings and defaults in next version of Ash.

For meanings it should mean "can it be read or written over public interface"/"can it be present in public interface". Because of the same meaning `accept` generated arguments will be able to inherit the option from its attribute. And to allow exposure of private attributes for writing in an action an option similar to `require_attributes` can/should be added.

For defaults arguments should match all other places and default to being private with publicity being opt-in.

Start by tracing how `public?` is defined for fields and arguments, then read how `accept` generates attribute arguments and how `require_attributes` works. The issue proposes aligning the meaning and defaults of `public?` and letting generated arguments inherit from their attributes, but leaves design choices open; clarify those before defining what done means.

Written by the indexing model from the issue text.