Feature Request: Mesh Proxy Message, Configurable Segmentation Strategy

There are two segmentation strategies described in the Mesh Profile (one of them integrated to the Network PDU spec, one of them only applicable to the GATT Proxy service):
- `Segment`s in the Lower Transport Layer (3.5.3 in the Mesh Profile spec)
- `SAR` as used in the proxy GATT service (6.3.2 in the Mesh Profile spec)

Currently in NimBLE it seems that Lower Transport Layer segmentation happens first, independently followed by Proxy Service SAR (if necessary). This presents a few issues:
1. Sending even a single large message via GATT Proxy requires increasing `BT_MESH_TX_SDU_MAX` to accommodate the whole mesh stack for this largest possible size. (Even if the large message is only sent proxy node->GATT client and could have used SAR with no segmentation)
2. Sending GATT proxy messages larger than the upper limit of `BT_MESH_TX_SDU_MAX` (even if possible via SAR) is [not permitted](https://github.com/apache/mynewt-nimble/blob/7be23d325293345858d3123975f7193311a7ea04/nimble/host/mesh/src/access.c#L634), as the possibility of SAR is not checked.
3. SAR is a more efficient use of the transport -- it can handle larger byte sizes and variable MTUs, with less overhead (fewer # of packets, fewer # of bytes, as well as fewer crypto operations).

I would like to be able to at least hint/specify that SAR should be preferred when sending a message, and ideally automagically have the optimal usage of segmentation strategies applied for any given payload.

Start at nimble/host/mesh/src/access.c around the cited BT_MESH_TX_SDU_MAX check. Read Mesh Profile sections 3.5.3 and 6.3.2 to compare Lower Transport segmentation with proxy SAR. Done should include a defined way to prefer or select SAR and support the requested larger proxy messages.

Written by the indexing model from the issue text.